All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linuxppc-dev@ozlabs.org
Cc: Timur Tabi <timur@freescale.com>
Subject: Re: [PATCH v2] qe: add ability to upload QE firmware
Date: Thu, 6 Dec 2007 01:17:14 +0100	[thread overview]
Message-ID: <200712060117.14768.arnd@arndb.de> (raw)
In-Reply-To: <47573CCE.4000606@freescale.com>

On Thursday 06 December 2007, Timur Tabi wrote:
> > In that case, I think it
> > would really be better to just put the blob into the tree and only
> > have the fw loading code in the kernel instead of duplicating it in the=
 boot
> > loader.
>=20
> That would require the firmware to present in RAM for all time, since the=
 device=20
> tree cannot be unloaded.

Yes, that's a backdraw of my approach, but in the case of spidernet, it was=
 only
an insignificant amount of RAM. Don't know what sizes of RAM and QE firmware
to expect typically on the machines you care about.

> Besides, you might need to have the firmware loaded in =20
> U-Boot anyway. =A0If your console is connected to the QE, then you'll nee=
d the=20
> UART firmware loaded before you can see anything. =A0That's why U-Boot ne=
eds its=20
> own version.

Right, so you can't really get around having it in some boot loaders at lea=
st.
IIRC you said that the firmware is only needed for serial output on some ch=
ips
but not on others. What about the case where you don't need it for serial b=
ut
still want to provide it by the firmware, and perhaps use something other t=
han
U-boot? Is that relevant?

I'm not trying to convince you of this if it's completely pointless for
all your systems, just want to make sure you're aware of this option,
because spending a few extra code lines on it now may save you some trouble
if you need this later.

> > Regarding the question whether the firmware should be a device node or
> > a property of another node, I'd prefer a simple property, because the
> > firmware itself is not really a device you can access, but I don't care
> > much about that.
>=20
> Technically, the firmware could be considered a device on the QE, because=
 it's=20
> loaded into I-RAM and it can significantly alter the behavior of the devi=
ce.=20

Well, it doesn't have any of the standard properties like registers or inte=
rrupts
though.

> Having it its own node also lets me compartmentalize it. =A0If I want to =
expand=20
> the node and add more properties, it's cleaner.

Yes, that makes a lot of sense.

	Arnd <><

  reply	other threads:[~2007-12-06  0:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-05 22:41 [PATCH v2] qe: add ability to upload QE firmware Timur Tabi
2007-12-05 23:31 ` Arnd Bergmann
2007-12-05 23:37   ` Timur Tabi
2007-12-05 23:56     ` Arnd Bergmann
2007-12-06  0:05       ` Timur Tabi
2007-12-06  0:17         ` Arnd Bergmann [this message]
2007-12-06 15:03           ` Timur Tabi
2007-12-06 15:31             ` Arnd Bergmann
2007-12-06 15:46               ` Timur Tabi
2007-12-06 15:58                 ` Arnd Bergmann
2007-12-06 15:59                   ` Timur Tabi
2007-12-06 16:02                     ` Kumar Gala
2007-12-06 16:12                       ` Timur Tabi
2007-12-06 17:25                         ` Timur Tabi

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=200712060117.14768.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=timur@freescale.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 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.