Re: linking static to dynamic devices
I forgot to add to my suggestion that enable() is only called if the 'present' flag is set. In this model you should be able to do the cpu fixups at the appropriate pass in enable(). Greg At 11:34 AM -0600 5/8/03, ron minnich wrote: On Tue, 5 Aug 2003, YhLu wrote: If you want cpufixup called by per cpu, you may need to modify cpu_initialize function and maybe add one pass for it. I plan to look at this tomorrow. ron Regards ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linking static to dynamic devices
If you want cpufixup called by per cpu, you may need to modify cpu_initialize function and maybe add one pass for it. Regards Yinghai Lu -邮件原件- 发件人: ron minnich [mailto:[EMAIL PROTECTED] 发送时间: 2003年8月5日 6:54 收件人: [EMAIL PROTECTED] 主题: linking static to dynamic devices The next obvious step is to link static to dynamic devices. One issue is that we define CPUs statically, up to the maximum the mainboard can take. But they may not be there. How do we express this? Greg had some ideas, so he may jump in once he gets off the plane. I do think the new static architecture will allow for things like cpufixup() calls per-cpu, etc. but we'll see. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linking static to dynamic devices
On Tue, 5 Aug 2003, YhLu wrote: > If you want cpufixup called by per cpu, you may need to modify > cpu_initialize function and maybe add one pass for it. I plan to look at this tomorrow. ron > > Regards ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linking static to dynamic devices
I'm not on the plane yet... :-)
My suggestion was to add an 'optional' keyword to the cpu device. So
you would declare something like:
cpu k8 "cpu0"
...
end
cpu k8 "cpu1"
optional
...
end
cpu k8 "cpu2"
optional
...
end
cpu k8 "cpu3"
optional
...
end
The effect of the optional keyword is to call a special function
"probe" which is added to the chip_control structure. probe() is
called before any calls to enable() and the result (0=success, <0
fail) is used to set a "present" flag in the chip structure. probe()
should not do anything else except check for existence (any other
configuration is done in enable()). Non-optional devices always have
their present flag set to 1.
struct chip_control {
void (*enable)(struct chip *, enum chip_pass);
int (*probe)(struct chip *);
char *path; /* the default path. Can be overridden
* by commands in config
*/
// This is the print name for debugging
char *name;
};
struct chip {
struct chip_control *control; /* for this device */
int present; /* device is present */
char *path; /* can be 0, in which case the default is taken */
char *configuration; /* can be 0. */
int irq;
struct chip *next, *children;
/* there is one of these for each INSTANCE of a chip */
void *chip_info; /* the dreaded "void *" */
};
Greg
At 7:54 AM -0600 5/8/03, ron minnich wrote:
The next obvious step is to link static to dynamic devices.
One issue is that we define CPUs statically, up to the maximum the
mainboard can take. But they may not be there. How do we express this?
Greg had some ideas, so he may jump in once he gets off the plane.
I do think the new static architecture will allow for things like
cpufixup() calls per-cpu, etc. but we'll see.
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
