From: Kumar Gala <kumar.gala@freescale.com>
To: "Jakob Viketoft" <jakob.viketoft@bitsim.se>
Cc: Jon Masters <jonathan@jonmasters.org>,
Sylvain Munaut <tnt@246tNt.com>,
Andrei Konovalov <akonovalov@ru.mvista.com>,
Linux PPC Embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: Platform bus/ppc sys model...
Date: Wed, 30 Mar 2005 11:26:55 -0600 [thread overview]
Message-ID: <111d2ae873d1bfee413409dfc4f2f064@freescale.com> (raw)
In-Reply-To: <424ACFF1.5000403@bitsim.se>
> My intention was to give a device tree structure to the kernel at boot
> time via a (pseudo?) pointer in bd_info or similar. Then you would only
> need to recompile a little bootloader (which is needed for setting up
> the FPGA anyway) with this structure for every specific card. You could
> even be shrewd enough to have a single kernel image but several
> structures to launch several processors on the same chip. Does it sound
> like a sane solution?
I think this is reasonable. The best device tree would be a flattened
OF tree since we are trying to move the world in that direction. Jon
Masters around?
> Otherwise, I'm a bit unsure as to whether a system with a gigantic list
> of devices in ???_devices.c is the right way to go. In the Xilinx case,
> not only is a list of possible IP:s needed, but also the usual standard
> circuits which can be connected from outside to the chip. Wouldn't it
> be
> more realistic to have knowledge of the compiled in drivers somehow?
Your needs are a bit different than the initial purpose of ppc_sys.
The reason the device list works well for us today is that it replaced
duplication between every variant of 85xx.
I'm not that familiar with exactly what information you would need to
have access to in the Xilinx case. I would think if you information
compiled into drivers some of this might all be moot. Part of the
whole device model is to have drivers that are agnostic of the system
they are in.
- kumar
next prev parent reply other threads:[~2005-03-30 17:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-30 8:00 Platform bus/ppc sys model Jakob Viketoft
2005-03-30 9:54 ` Sylvain Munaut
2005-03-30 13:52 ` Andrei Konovalov
2005-03-30 15:06 ` Kumar Gala
2005-03-30 16:12 ` Jakob Viketoft
2005-03-30 17:26 ` Kumar Gala [this message]
2005-03-31 12:33 ` Jon Masters
2005-03-31 15:55 ` Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...] Jon Loeliger
2005-04-04 7:20 ` Jakob Viketoft
2005-04-04 7:31 ` Jon Masters
2005-04-04 10:56 ` Andrei Konovalov
2005-04-04 11:01 ` Jon Masters
2005-04-04 11:08 ` Jakob Viketoft
2005-04-04 16:45 ` Wolfgang Denk
2005-04-04 16:58 ` Andrei Konovalov
2005-04-04 16:56 ` Jon Masters
2005-04-07 17:20 ` Tom Rini
2005-04-07 17:35 ` Jon Loeliger
2005-04-07 17:49 ` Tom Rini
2005-04-11 15:58 ` Jon Loeliger
2005-04-14 9:54 ` Jakob Viketoft
2005-04-15 14:22 ` Jon Loeliger
2005-04-22 17:33 ` Andrei Konovalov
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=111d2ae873d1bfee413409dfc4f2f064@freescale.com \
--to=kumar.gala@freescale.com \
--cc=akonovalov@ru.mvista.com \
--cc=jakob.viketoft@bitsim.se \
--cc=jonathan@jonmasters.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=tnt@246tNt.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.