From: Steve Calfee <stevecalfee@gmail.com>
To: Kevin Hilman <khilman@ti.com>
Cc: "Cousson, Benoit" <b-cousson@ti.com>,
"Menon, Nishanth" <nm@ti.com>,
linux-omap <linux-omap@vger.kernel.org>,
"Sonasath, Moiz" <m-sonasath@ti.com>
Subject: Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Date: Sun, 29 May 2011 14:04:29 -0700 [thread overview]
Message-ID: <BANLkTi==jZV13S1tzuRbWuoJytCZCBeWQg@mail.gmail.com> (raw)
In-Reply-To: <87oc2ox7bm.fsf@ti.com>
On Fri, May 27, 2011 at 12:38 PM, Kevin Hilman <khilman@ti.com> wrote:
> "Cousson, Benoit" <b-cousson@ti.com> writes:
>
> [...]
>
>> In general we do not want to reset nor idle an IP that was potentially
>> already properly configured by bootloader or early Linux boot code.
>
> Actually, the opposite is true.
>
> The kernel should not make any assumptions about what the bootloader has
> or has not done. We need to have a kernel that can boot from any
> bootloader (or none, like using kexec) and be able to start from a known
> hardware state.
>
YES. Bootloaders should only do what is necessary (set clocks, enable
memories etc) to load the next stage. Pushing stuff that should be in
the kernel into the bootloader (like iniiting gpios and other things)
bloats it and makes a developer deal with two entirely different
source trees (kernel and booterx) to enable a new feature or to fix
bugs.
Uboot tends to lag the kernel in capabilities too, probably because
fewer developers or something. For instance Beagleboard xm uboot
cannot access the ethernet because it is usb based, and uboot cannot
access its own environment in flash - because it is running from a new
microsd based flash system. U-boot will eventually catch up with
these, but by then other new hardware will be available.
Does anyone know if 2.6.39 has kexec working again for the kernel? NFS
boot is a dream development environment but with both u-boot and kexec
not working with nfs, it is slightly more work and less automated.
Regards, Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-05-29 21:04 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-26 1:56 [RFC][PATCH 0/9] OMAP4: Add 4460 base support Nishanth Menon
2011-05-26 1:56 ` [RFC][PATCH 1/9] OMAP: ID: introduce chip detection for OMAP4460 Nishanth Menon
2011-05-26 8:33 ` Premi, Sanjeev
2011-05-26 14:27 ` Nishanth Menon
2011-05-26 23:15 ` Kevin Hilman
2011-05-26 23:35 ` Menon, Nishanth
2011-05-26 1:56 ` [RFC][PATCH 2/9] OMAP4: HWMOD: make current hwmods common for 4460 and 4430 Nishanth Menon
2011-05-30 9:01 ` Vladimir Pantelic
2011-05-30 11:50 ` Nishanth Menon
2011-05-26 1:56 ` [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init Nishanth Menon
2011-05-26 8:36 ` Premi, Sanjeev
2011-05-26 14:28 ` Nishanth Menon
2011-05-26 23:24 ` Kevin Hilman
2011-05-26 23:37 ` Menon, Nishanth
2011-05-27 7:10 ` Cousson, Benoit
[not found] ` <BANLkTi=dHknRn5KJSh3_bG-o19BUg2AjrA@mail.gmail.com>
2011-05-27 12:16 ` Cousson, Benoit
2011-05-27 14:59 ` Kevin Hilman
2011-05-27 15:06 ` Cousson, Benoit
2011-05-27 19:35 ` Kevin Hilman
2011-05-27 19:38 ` Kevin Hilman
2011-05-29 1:11 ` Menon, Nishanth
2011-05-29 21:04 ` Steve Calfee [this message]
2011-05-30 8:32 ` Cousson, Benoit
2011-05-30 10:53 ` Koen Kooi
2011-05-26 1:56 ` [RFC][PATCH 4/9] OMAP4: clocks: distinguish 4430 and 4460 Nishanth Menon
2011-05-26 8:41 ` Premi, Sanjeev
2011-05-26 1:56 ` [RFC][PATCH 5/9] OMAP4: PRM: OMAP4460 specific PRM and CM register bitshifts Nishanth Menon
2011-05-26 1:56 ` [RFC][PATCH 6/9] OMAP4: clocks: Update the clock tree with 4460 clock nodes Nishanth Menon
2011-05-26 1:56 ` [RFC][PATCH 7/9] OMAP4: powerdomain: Update MPU powerdomain for 4460 Nishanth Menon
2011-05-26 8:52 ` Premi, Sanjeev
2011-05-26 14:30 ` Nishanth Menon
2011-05-26 1:56 ` [RFC][PATCH 8/9] OMAP4: clockdomain: Use CHIP_IS_44XX to reuse all CD's on 4460 Nishanth Menon
2011-05-26 8:47 ` Premi, Sanjeev
2011-05-26 1:56 ` [RFC][PATCH 9/9] OMAP4460: dpll: Support MPU frequencies > 1 Ghz Nishanth Menon
2011-05-26 3:16 ` Todd Poynor
2011-05-26 4:13 ` Rajendra Nayak
2011-05-26 4:53 ` Menon, Nishanth
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='BANLkTi==jZV13S1tzuRbWuoJytCZCBeWQg@mail.gmail.com' \
--to=stevecalfee@gmail.com \
--cc=b-cousson@ti.com \
--cc=khilman@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=m-sonasath@ti.com \
--cc=nm@ti.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;
as well as URLs for NNTP newsgroup(s).