8260 Memory Management

8260 Memory Management

[Allen Curtis]

Since the 8260 is based on a PPC 603e core, is there any reason why the
memory management should differ from the other Mac implementations? The real
difference is the CPM and the embedded peripheral support.

Would it be reasonable to make the 8260 memory management consistent with
the rest of the 6xx processors?


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

Re: 8260 Memory Management

[Dan Malek]

Allen Curtis wrote:

> Since the 8260 is based on a PPC 603e core, is there any reason why the
> memory management should differ from the other Mac implementations?

Well, yeah, it's not a Mac......

> Would it be reasonable to make the 8260 memory management consistent with
> the rest of the 6xx processors?

It is.  Please try to describe what you mean a little better.

Thanks.

	-- Dan


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

RE: 8260 Memory Management

[Allen Curtis]

> > Would it be reasonable to make the 8260 memory management
> consistent with
> > the rest of the 6xx processors?
>
> It is.  Please try to describe what you mean a little better.

Basically, remove all the CONFIG_8260 conditional compile stuff.

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

Re: 8260 Memory Management

[Dan Malek]

Allen Curtis wrote:

> Basically, remove all the CONFIG_8260 conditional compile stuff.

And what useful purpose do you expect this to do for us?


	-- Dan


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

RE: 8260 Memory Management

[Paul Mackerras]

Allen Curtis writes:

> Basically, remove all the CONFIG_8260 conditional compile stuff.

I just looked in arch/ppc in the linuxppc_2_4_devel tree and there are
only 3 places where CONFIG_8260 is used in the code.  Two of them are
for the cheesy request_8xxirq thing.  The other is for m8260_gorom.
So I'm not sure what you're referring to.

Dan, can we *please* take out the #define request_irq request_8xxirq
and just use request_irq like everyone else?

Paul.


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

Re: 8260 Memory Management

[Dan Malek]

Paul Mackerras wrote:

> Dan, can we *please* take out the #define request_irq request_8xxirq
> and just use request_irq like everyone else?

I was doing that as part of the 2.5 interrupt changes, but if you
want to do it now we can try.  On the 8260 it's not as bad as the 8xx,
but you have to ensure the legacy and PCI interrupts are outside of
the internal controller and CPM ranges.


	-- Dan


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

Re: 8260 Memory Management

[Paul Mackerras]

Dan Malek writes:

> I was doing that as part of the 2.5 interrupt changes, but if you
> want to do it now we can try.  On the 8260 it's not as bad as the 8xx,
> but you have to ensure the legacy and PCI interrupts are outside of
> the internal controller and CPM ranges.

Well... the #define request_irq request_8xxirq merely means that
including anything that calls request_irq will cause the kernel link
to fail.  Which I assume you put in to make sure you weren't linking
in any drivers that might assume legacy ISA irq numbers.

By now you must have got the configs, makefiles, etc. sorted out so
that you aren't including any unwanted drivers.  So the #define can be
removed.  Removing the #define and changing all the calls to
request_8xxirq to request_irq won't actually change any object code or
any runtime behaviour, it'll just look cleaner in the source code. :)

PCI interrupts aren't a problem because the platform code assigns the
interrupt numbers for each slot, and the drivers then just use that
(i.e. pci_dev->irq), and if they don't we shoot them.

Legacy interrupts aren't a problem because you just don't include the
driver, or else you set up the header files etc. so that the driver
doesn't make the wrong assumptions (e.g. serial.h).  So I don't see
any need to avoid using interrupt numbers 0-15 in general.  We use
interrupts 0-15 on powermac (they are often DBDMA completion
interrupts) without any problems.

Paul.

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

Re: 8260 Memory Management

[Tom Rini]

On Sat, Aug 24, 2002 at 10:28:08AM -0400, Dan Malek wrote:
>
> Paul Mackerras wrote:
>
> >Dan, can we *please* take out the #define request_irq request_8xxirq
> >and just use request_irq like everyone else?
>
> I was doing that as part of the 2.5 interrupt changes, but if you
> want to do it now we can try.  On the 8260 it's not as bad as the 8xx,
> but you have to ensure the legacy and PCI interrupts are outside of
> the internal controller and CPM ranges.

Well, for 2.4 and 8260, this is quite easily done, as was shown in the
patch which remove request_8xxirq altogether a while back.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: 8260 Memory Management

[acurtis]

> > Basically, remove all the CONFIG_8260 conditional compile stuff.
>
> And what useful purpose do you expect this to do for us?

Basically:
a) remove unnecessary inconsistencies within the PPC implementations
b) perhaps help with PCI stuff. The SYM SCSI drivers are working fine for all the
other PPC users but anyone that I have talked to with an 8260 has one problem or
another.

------------------------------------------------------------
Allen Curtis              |  All good things come to those
Ones and Zeros, Inc.      |  who wait. Some of us have to
mailto:acurtis@onz.com    |  wait a little longer.

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

RE: 8260 Memory Management

[acurtis]

> > Basically, remove all the CONFIG_8260 conditional compile stuff.
>
> I just looked in arch/ppc in the linuxppc_2_4_devel tree and there are
> only 3 places where CONFIG_8260 is used in the code.  Two of them are
> for the cheesy request_8xxirq thing.  The other is for m8260_gorom.
> So I'm not sure what you're referring to.

You need to look in include/asm-ppc. There is things related to address
translation too.

> Dan, can we *please* take out the #define request_irq request_8xxirq
> and just use request_irq like everyone else?

I already have a patch for this. Do you want it? I was getting ready to submit
several updates.

TIA

------------------------------------------------------------
Allen Curtis              |  All good things come to those
Ones and Zeros, Inc.      |  who wait. Some of us have to
mailto:acurtis@onz.com    |  wait a little longer.

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