From: Scott Wood <scottwood@freescale.com> To: Matt Sealey <matt@genesi-usa.com> Cc: David Brown <davidb@codeaurora.org>, Sascha Hauer <s.hauer@pengutronix.de>, devicetree-discuss@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, patches@linaro.org Subject: Re: [PATCH 1/2] arm/mx5: parse iomuxc pad configuratoin from device tree Date: Fri, 5 Aug 2011 15:26:29 -0500 [thread overview] Message-ID: <4E3C51F5.50707@freescale.com> (raw) In-Reply-To: <CAKGA1bkM6X533w20hDV7GCPwzzj2nrjGdN6zkXsS+hCvUD_s2A@mail.gmail.com> On 08/05/2011 01:36 PM, Matt Sealey wrote: > On Fri, Aug 5, 2011 at 2:07 AM, David Brown <davidb@codeaurora.org> wrote: >> On Thu, Aug 04, 2011 at 06:07:15PM -0500, Matt Sealey wrote: >>> Hi Grant, Shawn, >>> >>> On Mon, Jul 25, 2011 at 3:46 PM, Grant Likely <grant.likely@secretlab.ca> wrote: >>>> This could get really verbose in a really big hurry. Fortunately the >>>> dtb format is sophisticated enough to only store each unique property >>>> name once, so the data shouldn't be huge, but it is still going to >>>> make for huge source files. Can you think of a more concise >>>> representation? >>> >>> Yes: no representation at all. The correct place for IOMUX setup being >>> done is *inside the boot firmware as soon as physically possible* and >>> not seconds into boot after U-Boot has made a console, done a boot >>> timeout, loaded scripts, kernels and ramdisks from media and then >>> uncompressed and entered a Linux kernel. >> >> This is true in situations where we have control over the bootloader, >> but that isn't always the case. > > Indeed it is not, but then it is "their" fault the board won't boot > Linux, and not yours, right? :) > > I think it is a given that when designing hardware (and we do that) > and proprietary firmware that the Linux kernel guys can't "control", > you have to keep up with the changes when reasonable. While sometimes > that is very difficult, this is not one of those "sometimes" - > providing a setup that can boot Linux implies that you configured the > chip correctly such that Linux is supplementing that configuration, > not reimplementing it from scratch. In the absence of a time machine, situations where one might not want to upgrade firmware are not limited to proprietary firmware. The means to recover from a bricked board are not always available and convenient. This is why we did pin setup in Linux for 8xx/82xx, and why we did cuImage. If you haven't yet shipped the boards with bad firmware to an extent that requires compatibility, that's a different situation of course. > Yes, it puts the onus of the work on the firmware guys, but they're > the ones writing the device trees for their hardware anyway. Sometimes. -Scott
WARNING: multiple messages have this Message-ID (diff)
From: scottwood@freescale.com (Scott Wood) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/2] arm/mx5: parse iomuxc pad configuratoin from device tree Date: Fri, 5 Aug 2011 15:26:29 -0500 [thread overview] Message-ID: <4E3C51F5.50707@freescale.com> (raw) In-Reply-To: <CAKGA1bkM6X533w20hDV7GCPwzzj2nrjGdN6zkXsS+hCvUD_s2A@mail.gmail.com> On 08/05/2011 01:36 PM, Matt Sealey wrote: > On Fri, Aug 5, 2011 at 2:07 AM, David Brown <davidb@codeaurora.org> wrote: >> On Thu, Aug 04, 2011 at 06:07:15PM -0500, Matt Sealey wrote: >>> Hi Grant, Shawn, >>> >>> On Mon, Jul 25, 2011 at 3:46 PM, Grant Likely <grant.likely@secretlab.ca> wrote: >>>> This could get really verbose in a really big hurry. Fortunately the >>>> dtb format is sophisticated enough to only store each unique property >>>> name once, so the data shouldn't be huge, but it is still going to >>>> make for huge source files. Can you think of a more concise >>>> representation? >>> >>> Yes: no representation at all. The correct place for IOMUX setup being >>> done is *inside the boot firmware as soon as physically possible* and >>> not seconds into boot after U-Boot has made a console, done a boot >>> timeout, loaded scripts, kernels and ramdisks from media and then >>> uncompressed and entered a Linux kernel. >> >> This is true in situations where we have control over the bootloader, >> but that isn't always the case. > > Indeed it is not, but then it is "their" fault the board won't boot > Linux, and not yours, right? :) > > I think it is a given that when designing hardware (and we do that) > and proprietary firmware that the Linux kernel guys can't "control", > you have to keep up with the changes when reasonable. While sometimes > that is very difficult, this is not one of those "sometimes" - > providing a setup that can boot Linux implies that you configured the > chip correctly such that Linux is supplementing that configuration, > not reimplementing it from scratch. In the absence of a time machine, situations where one might not want to upgrade firmware are not limited to proprietary firmware. The means to recover from a bricked board are not always available and convenient. This is why we did pin setup in Linux for 8xx/82xx, and why we did cuImage. If you haven't yet shipped the boards with bad firmware to an extent that requires compatibility, that's a different situation of course. > Yes, it puts the onus of the work on the firmware guys, but they're > the ones writing the device trees for their hardware anyway. Sometimes. -Scott
next prev parent reply other threads:[~2011-08-05 20:26 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-07-25 15:07 [PATCH 0/2] Add device tree support for i.mx53 boards Shawn Guo 2011-07-25 15:07 ` Shawn Guo [not found] ` <1311606467-28985-1-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2011-07-25 15:07 ` [PATCH 1/2] arm/mx5: parse iomuxc pad configuratoin from device tree Shawn Guo 2011-07-25 15:07 ` Shawn Guo [not found] ` <1311606467-28985-2-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2011-07-25 20:46 ` Grant Likely 2011-07-25 20:46 ` Grant Likely [not found] ` <20110725204630.GD26735-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2011-07-26 2:43 ` Shawn Guo 2011-07-26 2:43 ` Shawn Guo [not found] ` <20110726024354.GI21641-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org> 2011-07-26 6:29 ` Sascha Hauer 2011-07-26 6:29 ` Sascha Hauer 2011-07-26 16:34 ` Shawn Guo 2011-07-26 16:34 ` Shawn Guo 2011-07-31 4:02 ` Grant Likely 2011-07-31 4:02 ` Grant Likely 2011-07-26 11:19 ` Eric Miao 2011-07-26 11:19 ` Eric Miao 2011-08-04 23:07 ` Matt Sealey 2011-08-04 23:07 ` Matt Sealey [not found] ` <CAKGA1bmbWUeyhUtDwHZjB8V4e2wJ0NHX2qWhqaqx6HoBm7uMnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-08-05 7:07 ` David Brown 2011-08-05 7:07 ` David Brown [not found] ` <20110805070729.GA26563-AOX6H5vLt3Uj8izMo0bVsAC/G2K4zDHf@public.gmane.org> 2011-08-05 18:36 ` Matt Sealey 2011-08-05 18:36 ` Matt Sealey 2011-08-05 20:26 ` Scott Wood [this message] 2011-08-05 20:26 ` Scott Wood 2011-08-05 20:36 ` David Brown 2011-08-05 20:36 ` David Brown [not found] ` <20110805203629.GB6991-AOX6H5vLt3Uj8izMo0bVsAC/G2K4zDHf@public.gmane.org> 2011-08-05 21:29 ` Matt Sealey 2011-08-05 21:29 ` Matt Sealey 2011-08-05 21:48 ` Scott Wood 2011-08-05 21:48 ` Scott Wood 2011-08-06 17:41 ` Grant Likely 2011-08-06 17:41 ` Grant Likely [not found] ` <CAKGA1bkM6X533w20hDV7GCPwzzj2nrjGdN6zkXsS+hCvUD_s2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-08-07 16:23 ` Russell King - ARM Linux 2011-08-07 16:23 ` Russell King - ARM Linux 2011-08-05 22:58 ` Grant Likely 2011-08-05 22:58 ` Grant Likely [not found] ` <20110805225845.GC6404-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2011-08-05 23:31 ` Mitch Bradley 2011-08-05 23:31 ` Mitch Bradley 2011-08-06 3:47 ` Mark Brown 2011-08-06 3:47 ` Mark Brown 2011-08-07 11:15 ` Sascha Hauer 2011-08-07 11:15 ` Sascha Hauer 2011-07-26 6:31 ` Sascha Hauer 2011-07-26 6:31 ` Sascha Hauer 2011-07-26 16:39 ` Shawn Guo 2011-07-26 16:39 ` Shawn Guo 2011-07-26 6:39 ` Sascha Hauer 2011-07-26 6:39 ` Sascha Hauer 2011-07-26 16:41 ` Shawn Guo 2011-07-26 16:41 ` Shawn Guo 2011-07-25 15:07 ` [PATCH 2/2] arm/mx5: add device tree support for imx53 boards Shawn Guo 2011-07-25 15:07 ` Shawn Guo [not found] ` <1311606467-28985-3-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2011-07-25 20:57 ` Grant Likely 2011-07-25 20:57 ` Grant Likely
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=4E3C51F5.50707@freescale.com \ --to=scottwood@freescale.com \ --cc=davidb@codeaurora.org \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=matt@genesi-usa.com \ --cc=patches@linaro.org \ --cc=s.hauer@pengutronix.de \ /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: linkBe 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.