4xx change to core files

4xx change to core files

[Armin]

I have changed the way the paddrs are used in the 4xx specifically in
the manner they are used in the core.c files.  This eliminates the need
for "externs struct *_ADDR[]" , IIC_PORT_DFNS and in most cases the need
for *_NUMS.  The ocp API's have changed to take advantage of this new
core_ocp[].  All the ocp drivers have been affected in a minor way as
well as most core.h files.

The core_ocp[] is don ein the following:

new struct in asm-ppc/ocp.h

struct ocp_def {
	enum ocp_type type;
	int paddr;
	int irq;
};


each 4xx core file now contains something simulary to this ( ibm405gp.c)

struct ocp_def core_ocp[] = {
	{UART, UART0_IO_BASE, UART0_INT},
	{UART, UART1_IO_BASE, UART1_INT},
	{IIC, IIC0_BASE, IIC0_IRQ},
	{GPIO, GPIO0_BASE, OCP_IRQ_NA},
	{PCI, PCIL0_BASE, OCP_IRQ_NA},
	{OPB, OPB0_BASE, OCP_IRQ_NA},
	{EMAC, EMAC0_BASE, OCP_IRQ_NA},
	{OCP_NULL_TYPE, 0x0, OCP_IRQ_NA},

};


new ocp APIs:

unsigned long get_ocp_paddr(int type, int dev_num);
  returns the physical address for a given ocp type for the nth one.
  this is used when the mmu is not completely up such as during pci
bring up.

int ocp_get_max(int type);
   returns the max number of ocp device type


  This affects the 405gp, np405l, np405h, 440gp , stb03xxx, stb04xxx and
np4gs cores.


the following drivers have been altered, ibm_ocp_enet.c, ibm_ocp_zmii.c,
ppc405_pci.c, ibm_ocp_gpio.c, i2c-adapt-ibm_ocp.c

I expect to be done soon.

Armin


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

Re: 4xx change to core files

[Matt Porter]

On Wed, May 08, 2002 at 09:45:02AM -0700, Armin wrote:
> The core_ocp[] is don ein the following:
>
> new struct in asm-ppc/ocp.h
>
> struct ocp_def {
> 	enum ocp_type type;
> 	int paddr;
> 	int irq;
> };
 };

<snip>

> new ocp APIs:
>
> unsigned long get_ocp_paddr(int type, int dev_num);
>   returns the physical address for a given ocp type for the nth one.
>   this is used when the mmu is not completely up such as during pci
> bring up.

It would be helpful for 36-bit 4xx core implementations (440gp/440gx)
if the paddr used the phys_addr_t typedef so we could store a
native 64-bit address.

It would appear to me that one would expect to be able to do
the following:

	ioremap(get_ocp_paddr(<type>, <num>), <size>);

Is that the intention?

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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

Re: 4xx change to core files

[andrew may]

On Wed, May 08, 2002 at 09:45:02AM -0700, Armin wrote:
> struct ocp_def core_ocp[] = {
> 	{UART, UART0_IO_BASE, UART0_INT},
> 	{UART, UART1_IO_BASE, UART1_INT},
> 	{IIC, IIC0_BASE, IIC0_IRQ},
> 	{GPIO, GPIO0_BASE, OCP_IRQ_NA},
> 	{PCI, PCIL0_BASE, OCP_IRQ_NA},
> 	{OPB, OPB0_BASE, OCP_IRQ_NA},
> 	{EMAC, EMAC0_BASE, OCP_IRQ_NA},
> 	{OCP_NULL_TYPE, 0x0, OCP_IRQ_NA},
>
> };

It would be nice if the global struct ocp_def core_ocp was just a pointer.
Then in a ibm405gp.c and friends could have a static of the entire stucture
and set the global pointer to it.

That should be a pretty straight forward change. The only change to code
that use core_ocp would be maybe a NULL check, but even that could be avoided.

The great thing about these chips is that you can stamp down different OCP's
as needed regaurdless of the actual CPU type.

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

Re: 4xx change to core files

[Armin]

Matt Porter wrote:
> On Wed, May 08, 2002 at 09:45:02AM -0700, Armin wrote:
>
>>The core_ocp[] is don ein the following:
>>
>>new struct in asm-ppc/ocp.h
>>
>>struct ocp_def {
>>	enum ocp_type type;
>>	int paddr;
>>	int irq;
>>};
>>
>  };
>
> <snip>
>
>>new ocp APIs:
>>
>>unsigned long get_ocp_paddr(int type, int dev_num);
>>  returns the physical address for a given ocp type for the nth one.
>>  this is used when the mmu is not completely up such as during pci
>>bring up.
>>
>
> It would be helpful for 36-bit 4xx core implementations (440gp/440gx)
> if the paddr used the phys_addr_t typedef so we could store a
> native 64-bit address.

ok

>
> It would appear to me that one would expect to be able to do
> the following:
>
> 	ioremap(get_ocp_paddr(<type>, <num>), <size>);
>
> Is that the intention?


Yeap


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

Re: 4xx change to core files

[Matt Porter]

On Wed, May 08, 2002 at 12:08:51PM -0700, Armin wrote:
> Matt Porter wrote:
> >On Wed, May 08, 2002 at 09:45:02AM -0700, Armin wrote:
> >
> >>The core_ocp[] is don ein the following:
> >>
> >>new struct in asm-ppc/ocp.h
> >>
> >>struct ocp_def {
> >>	enum ocp_type type;
> >>	int paddr;
> >>	int irq;
> >>};
> >>
> > };
> >
> ><snip>
> >
> >>new ocp APIs:
> >>
> >>unsigned long get_ocp_paddr(int type, int dev_num);
> >> returns the physical address for a given ocp type for the nth one.
> >> this is used when the mmu is not completely up such as during pci
> >>bring up.
> >>
> >
> >It would be helpful for 36-bit 4xx core implementations (440gp/440gx)
> >if the paddr used the phys_addr_t typedef so we could store a
> >native 64-bit address.
>
> ok
>
> >
> >It would appear to me that one would expect to be able to do
> >the following:
> >
> >	ioremap(get_ocp_paddr(<type>, <num>), <size>);
> >
> >Is that the intention?
>
>
> Yeap

Ok, then the other piece that will be necessary is to
change to using a 'ioremap_native' for the ocp drivers.
That will resolve to 'ioremap' on 32-bit phys cores and
'ioremap64' on 36+-bit phys cores.

I'm able to "fixup" 32-bit phys addrs in the 440-specific
ioremap on the 440gp since the memory map luckily provided
unique (least significant 32-bit) addresses.  This is
may or may not work on upcoming 440+ implementations as
the memory maps will differ...possibly having I/O regions
overlapping in their least significant 32-bits.

Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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