RE: Removing device driver code in mainboard.c for Tyan boards?

[YhLu]

I changed e7501 to use root_complex too.

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Friday, November 05, 2004 11:34 AM
To: YhLu; [e-mail]
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

Eric,

If the chip_ops has no .name, then should use
if CONFIG_CHIP_NAME 
    config chip.h 
end

also .c include that chip_ops
#if CONFIG_CHIP_NAME
...chip_ops defininition
#endif

Regards

Such as norththbridge, socket, mainboard(root).

YH

Removing device driver code in mainboard.c for Tyan boards?

YhLu  writes:
> I changed e7501 to use root_complex too.

Could we please reserve this construct for chipsets
with multiple northbridges?

I think it is just going to be extra noise on a
simple chipset like the e7501.

And since the e7501 is an example to a certain extent having it
doing extra work be confusing and a pain.
> If the chip_ops has no .name, then should use
> if CONFIG_CHIP_NAME 
>    config chip.h 
> end
>
> also .c include that chip_ops
> #if CONFIG_CHIP_NAME
> ...chip_ops defininition
> #endif
>
> Regards
>
> Such as norththbridge, socket, mainboard(root).

They can.  But I am about to suggest simply removing the config
directive, and assuming the ``config chip.h'' is always given.  The
overhead is almost zero for a zero filled structure.  And always
requiring a chip.h would tend to simply the process of writing code
for a new chip.

Eric

PPC types

[Stefan Reinauer]

For PPC there are two types of lb_memory_range defined.

which one should be used? (uint64_t is save probably)

void lb_memory_range(struct lb_memory *mem,
        uint32_t type, unsigned long startk, unsigned long sizek);

void lb_memory_range(struct lb_memory *mem,
                        uint32_t type, uint64_t start, uint64_t size)

Eric,

limits.h is pretty much overkill in div64.h, we just need ULONG_MAX
which we could place somewhere within our arch dependent files...

Stefan

Removing device driver code in mainboard.c for Tyan boards?

[Ronald G. Minnich]

On Fri, 5 Nov 2004, Eric W. Biederman wrote:
> Could we please reserve this construct for chipsets
> with multiple northbridges?

Whew, I'm glad you said that Eric, it concerned me too!

thanks

ron

Removing device driver code in mainboard.c for Tyan boards?

"Ronald G. Minnich"  writes:
> On Fri, 5 Nov 2004, Eric W. Biederman wrote:
> > Could we please reserve this construct for chipsets
> > with multiple northbridges?
>
> Whew, I'm glad you said that Eric, it concerned me too!

This is not something I think it is worth much of an argument about.

I think doing this with the E7501 makes is less good as an example,
for other boards.

Except for chipsets with multiple northbridges I don't intend to
use the root_complex structure.

When you have multiple northbridges it nicely makes the information
we specify per northbridge symmetric.  Which helps in a lot
of little ways.  But for a single chipset it really is unnecessary.
It is the device's that really cary structure information and we have
all of those, one way or another.

Eric

Removing device driver code in mainboard.c for Tyan boards?

[Ronald G. Minnich]

On Fri, 5 Nov 2004, Eric W. Biederman wrote:
> They can.  But I am about to suggest simply removing the config
> directive, and assuming the ``config chip.h'' is always given.  The
> overhead is almost zero for a zero filled structure.  And always
> requiring a chip.h would tend to simply the process of writing code
> for a new chip.

yes, I think Eric is right on this one too :-)

ron

Removing device driver code in mainboard.c for Tyan boards?

"Ronald G. Minnich"  writes:
> On Fri, 5 Nov 2004, Eric W. Biederman wrote:
> > They can.  But I am about to suggest simply removing the config
> > directive, and assuming the ``config chip.h'' is always given.  The
> > overhead is almost zero for a zero filled structure.  And always
> > requiring a chip.h would tend to simply the process of writing code
> > for a new chip.
>
> yes, I think Eric is right on this one too :-)

I think we probably want to wait a little on this one.
YhLu is extremely tight on space right now and I think
that needs to be addressed before we require any more
slight size increases.

Eric