RFC: gt64260 descriptor struct

RFC: gt64260 descriptor struct

[Brian Waite]

I know this was very briefly discussed in the past but I am in need of doing
this right so lets start up the discussion again.

The gt64260 code relies on many defines and/or fw values when it should not.
For example the MPSC and eth both pull from a define or bi_struct for certain
information. We all agree this is not good. In house I now have 2 new
drivers, i2c and timer 4, that also would like some of this info.

What we need is a global structure for gt code that will describe the features
of the gt and export that to drivers that need it. What I see right now for
required elements are:

typdef struct gt64260_features {
	unsigned long mem_size;
	unsigned long bus_speed /* in Hz */
	unsigned char eth1addr[6];
	unsigned char eth2addr[6];
	unsigned char eth3addr[6];
	unsigned long baudrate;
} gt64260_features_t;


I really would like to hear from other gt developers and anyone else about
this being a good or bad idea. I am not sure we even need all of these
elements in the struct, ie gt64260_base, but I was looking for places we
conditionally look at the bd_t. Any thoughts?

Thanks
Brian

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RFC: gt64260 descriptor struct

[Matt Porter]

On Thu, Feb 27, 2003 at 10:31:27AM -0500, Brian Waite wrote:
> What we need is a global structure for gt code that will describe the features
> of the gt and export that to drivers that need it. What I see right now for
> required elements are:

All peripherals that don't have intelligent discovery mechanisms could
make use of the OCP layer that 4xx uses.  gt64260, mpc10x, etc could
easily follow this same model that provides a standard device info.
discovery interface.  Of course, the OCP stuff in 2_4_devel is due
to be changed to match that of 2.5 is the near future...benh is
working on that.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RFC: gt64260 descriptor struct

[Brian Waite]

Do you have any good pointers besides code on the implementation? I am reading
the code now to figure out how to make it work. On first look I think it will
fit, but I am not sure. I definitely see it as solving a different problem to
what I am trying to solve. Maybe this is due to my naivety on the OCP modle,
but I need to pass through infomation from the FW that is not determinable by
code. MAC addresses, for example are not stored in the GT64260. Instead, they
are either passed on the commandline or passed via PPCBoot. The same goes
with bus speed, the bus speed cannot be determined by any registers on the
gt64260. I need to preserve certain peices of information for uppper level
drivers regardless of if I am using OCP or not. I hope I am missing some on
the details of OCP and I can overcome my problem by using the OCP layer, but
I am not sure yet. Any thoughts?

Thanks
Brian



On Thursday 27 February 2003 11:27 am, Matt Porter wrote:
> On Thu, Feb 27, 2003 at 10:31:27AM -0500, Brian Waite wrote:
> > What we need is a global structure for gt code that will describe the
> > features of the gt and export that to drivers that need it. What I see
> > right now for required elements are:
>
> All peripherals that don't have intelligent discovery mechanisms could
> make use of the OCP layer that 4xx uses.  gt64260, mpc10x, etc could
> easily follow this same model that provides a standard device info.
> discovery interface.  Of course, the OCP stuff in 2_4_devel is due
> to be changed to match that of 2.5 is the near future...benh is
> working on that.
>
> Regards,


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RFC: gt64260 descriptor struct

[Matt Porter]

On Thu, Feb 27, 2003 at 01:01:10PM -0500, Brian Waite wrote:
> Do you have any good pointers besides code on the implementation? I am reading
> the code now to figure out how to make it work. On first look I think it will
> fit, but I am not sure. I definitely see it as solving a different problem to
> what I am trying to solve. Maybe this is due to my naivety on the OCP modle,
> but I need to pass through infomation from the FW that is not determinable by
> code. MAC addresses, for example are not stored in the GT64260. Instead, they
> are either passed on the commandline or passed via PPCBoot. The same goes
> with bus speed, the bus speed cannot be determined by any registers on the
> gt64260. I need to preserve certain peices of information for uppper level
> drivers regardless of if I am using OCP or not. I hope I am missing some on
> the details of OCP and I can overcome my problem by using the OCP layer, but
> I am not sure yet. Any thoughts?

The suggestion to use OCP was directed at the portion of your problem
that is involved in getting the information into the standalone device
drivers.  Getting the information from the boot wrapper code (which might
derive the value from i2c or some other magical place) can be accomplish
using a bd_t like lots of other platforms do.  8xx/4xx, etc.

That gets whatever board specific information (mac addresses, freqs, etc.)
into the kernel.  Then you combine that with a chipset specific
(64260, 360 x60) specific descriptor file that defines the number, irq,
base address type information for a specific system controller variant.
Then you can have an ethernet driver that written to OCP API, will
gather both chipset-specific and board-specific information in a way
that makes the driver very readable.

The bd_t structure can be defined on a per-subarch/board level to
accomodate the fields needed. See evb405ep.h, beech.h, ranier.h,
redwood6.h, etc.

The need to do this type of thing is common across CPC700,CPC710,GT64x60,
MCG Hawk, MCG Harrier,MPC10x,MPC824x, MPC8xx,MPC825x,MPC826x,MPC85xx,PPC4xx
so for readability sake we might as well all do something similar.

-Matt

> On Thursday 27 February 2003 11:27 am, Matt Porter wrote:
> > On Thu, Feb 27, 2003 at 10:31:27AM -0500, Brian Waite wrote:
> > > What we need is a global structure for gt code that will describe the
> > > features of the gt and export that to drivers that need it. What I see
> > > right now for required elements are:
> >
> > All peripherals that don't have intelligent discovery mechanisms could
> > make use of the OCP layer that 4xx uses.  gt64260, mpc10x, etc could
> > easily follow this same model that provides a standard device info.
> > discovery interface.  Of course, the OCP stuff in 2_4_devel is due
> > to be changed to match that of 2.5 is the near future...benh is
> > working on that.
> >
> > Regards,

--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/