Regarding consistent_alloc

Regarding consistent_alloc

[Pantelis Antoniou]

Hi

Can someone tell what is the deal with these functions?

consistent_alloc et. al. are very useful to me now that I'm
cleaning up my QMC driver. But they are exported.

Is there any reason why they are not exported for use by
modules?

Also they appear to be tied to the PCI bus, a reduntant
dependancy IMHO.

Regards

--
Pantelis Antoniou
INTRACOM S.A. Greece

"> I read slashdot because it's so hard to find
 >> anything else intelligent to read.

Keep searching..."
-- as seen on slashdot --


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

Re: Regarding consistent_alloc

[Pantelis Antoniou]

Pantelis Antoniou wrote:

>
> Hi
>
> Can someone tell what is the deal with these functions?

                   ^ me

>
>
> consistent_alloc et. al. are very useful to me now that I'm
> cleaning up my QMC driver. But they are exported.

                                         ^ not

>
>
> Is there any reason why they are not exported for use by
> modules?
>
> Also they appear to be tied to the PCI bus, a reduntant
> dependancy IMHO.
>
> Regards
>
> --
> Pantelis Antoniou
> INTRACOM S.A. Greece
>
> "> I read slashdot because it's so hard to find
> >> anything else intelligent to read.
>
> Keep searching..."
> -- as seen on slashdot --
>
>
>
>

Sigh,

Maybe I should read the mail more before hitting send.




--
Pantelis Antoniou
INTRACOM S.A. Greece

"> I read slashdot because it's so hard to find
>> anything else intelligent to read.

Keep searching..."
-- as seen on slashdot --


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

RE: Regarding consistent_alloc

[Joakim Tjernlund]

Hi

If you implement the performance improvement I suggested earlier, I don't think
you need them. Another thing with consistent_xxx() is that you can not use
__pa() and __va() on addresses returned by the consistent_alloc et. al.

I think Dan Malek and/or Tom Rini knows more about these functions.

   Jocke

>
> Pantelis Antoniou wrote:
>
> >
> > Hi
> >
> > Can someone tell what is the deal with these functions?
>
>                    ^ me
>
> >
> >
> > consistent_alloc et. al. are very useful to me now that I'm
> > cleaning up my QMC driver. But they are exported.
>
>                                          ^ not
>
> >
> >
> > Is there any reason why they are not exported for use by
> > modules?
> >
> > Also they appear to be tied to the PCI bus, a reduntant
> > dependancy IMHO.
> >
> > Regards
> >
> > --
> > Pantelis Antoniou
> > INTRACOM S.A. Greece
> >
> > "> I read slashdot because it's so hard to find
> > >> anything else intelligent to read.
> >
> > Keep searching..."
> > -- as seen on slashdot --
> >
> >
> >
> >
>
> Sigh,
>
> Maybe I should read the mail more before hitting send.
>
>
>
>
> --
> Pantelis Antoniou
> INTRACOM S.A. Greece
>
> "> I read slashdot because it's so hard to find
> >> anything else intelligent to read.
>
> Keep searching..."
> -- as seen on slashdot --
>
>
>
>


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

Re: Regarding consistent_alloc

[Matt Porter]

On Fri, Dec 06, 2002 at 03:18:21PM +0200, Pantelis Antoniou wrote:
>
> Hi
>
> Can someone tell what is the deal with these functions?
>
> consistent_alloc et. al. are very useful to me now that I'm
> cleaning up my QMC driver. But they are exported.
>
> Is there any reason why they are not exported for use by
> modules?

They are exported in the development trees I use, linuxppc_2_4_devel
and linuxppc-2.5.

> Also they appear to be tied to the PCI bus, a reduntant
> dependancy IMHO.

How so?  consistent_alloc/consistent_free are independent of pci bus.
Use those.  pci_* are, by definition, pci-specific and only exported
on PCI-based systems.

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

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

Re: Regarding consistent_alloc

[Matt Porter]

On Fri, Dec 06, 2002 at 03:25:48PM +0100, Joakim Tjernlund wrote:
> If you implement the performance improvement I suggested earlier, I don't think
> you need them. Another thing with consistent_xxx() is that you can not use
> __pa() and __va() on addresses returned by the consistent_alloc et. al.

Um, well if you are doing a consistent_alloc() then surely you are
keeping the dma_handle around which is your physical address.  If you
want the kernel virtual address then you can apply __va to that.  So,
you have the cache inhibited mapping in vmalloc space returned to you,
the physical address provided in dma_handle, and a kernel virtual address
that can be trivially generated.

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

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

RE: Regarding consistent_alloc

[Joakim Tjernlund]

>
> On Fri, Dec 06, 2002 at 03:25:48PM +0100, Joakim Tjernlund wrote:
> > If you implement the performance improvement I suggested earlier, I don't think
> > you need them. Another thing with consistent_xxx() is that you can not use
> > __pa() and __va() on addresses returned by the consistent_alloc et. al.
>
> Um, well if you are doing a consistent_alloc() then surely you are
> keeping the dma_handle around which is your physical address.  If you
> want the kernel virtual address then you can apply __va to that.  So,
> you have the cache inhibited mapping in vmalloc space returned to you,
> the physical address provided in dma_handle, and a kernel virtual address
> that can be trivially generated.

m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work
on addresses returned by m8xx_cpm_hostalloc(). I just found that out the
hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver
hung as soon you tried to read something.

Not sure about __va() but there is a comment in 8xx_io/enet.c that it does not work
anymore.

Perhaps this is so only for early calls to consistent_alloc(during the init phase)?

  Jocke

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


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

Re: Regarding consistent_alloc

[Dan Malek]

Matt Porter wrote:

 > ....  If you
> want the kernel virtual address then you can apply __va to that.

Errr....no, you can't.  That would give you the cached mapping.
You need to hang on to both the dma_handle (the phys address token)
and the virtual address returned by the function.  That's why both
are returned.


	-- Dan


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

RE: Regarding consistent_alloc

[Joakim Tjernlund]

>
> On Fri, Dec 06, 2002 at 05:08:22PM +0100, Joakim Tjernlund wrote:
> > >
> > > On Fri, Dec 06, 2002 at 03:25:48PM +0100, Joakim Tjernlund wrote:
> > > > If you implement the performance improvement I suggested earlier, I don't think
> > > > you need them. Another thing with consistent_xxx() is that you can not use
> > > > __pa() and __va() on addresses returned by the consistent_alloc et. al.
> > >
> > > Um, well if you are doing a consistent_alloc() then surely you are
> > > keeping the dma_handle around which is your physical address.  If you
> > > want the kernel virtual address then you can apply __va to that.  So,
> > > you have the cache inhibited mapping in vmalloc space returned to you,
> > > the physical address provided in dma_handle, and a kernel virtual address
> > > that can be trivially generated.
> >
> > m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work
> > on addresses returned by m8xx_cpm_hostalloc(). I just found that out the
> > hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver
>
> that's a problem with m8xx_cpm_hostalloc() (or how you are using it) if
> it doesn't keep around the values you need.
>

Yes and no, someone changed the m8xx_cpm_hostalloc() implementation and now
it does not behave as it used to. Earlier both __pa(adr) and __va(__pa(adr))
worked on addresses returned by m8xx_cpm_hostalloc().

I think in it's current form it's useless and should either be changed back to what
it was or die.

   Jocke


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

Re: Regarding consistent_alloc

[Matt Porter]

On Fri, Dec 06, 2002 at 11:56:22AM -0500, Dan Malek wrote:
> Matt Porter wrote:
>
>  > ....  If you
> > want the kernel virtual address then you can apply __va to that.
>
> Errr....no, you can't.  That would give you the cached mapping.
> You need to hang on to both the dma_handle (the phys address token)
> and the virtual address returned by the function.  That's why both
> are returned.

That's what I said...but you clipped it out.  Once again,
consistent_alloc provides the caller everything they need.
An uncached mapping, a phys address, and from that you can use
__va() to get the cached mapping.

Seemed clear enough to me the first time.  My definition of a
"kernel virtual address" is the lowmem cached mapping.  If
I meant the uncached mapping I would have said it was a "kernel
vmalloc address" or something. :)

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

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

Re: Regarding consistent_alloc

[Matt Porter]

On Fri, Dec 06, 2002 at 05:08:22PM +0100, Joakim Tjernlund wrote:
> >
> > On Fri, Dec 06, 2002 at 03:25:48PM +0100, Joakim Tjernlund wrote:
> > > If you implement the performance improvement I suggested earlier, I don't think
> > > you need them. Another thing with consistent_xxx() is that you can not use
> > > __pa() and __va() on addresses returned by the consistent_alloc et. al.
> >
> > Um, well if you are doing a consistent_alloc() then surely you are
> > keeping the dma_handle around which is your physical address.  If you
> > want the kernel virtual address then you can apply __va to that.  So,
> > you have the cache inhibited mapping in vmalloc space returned to you,
> > the physical address provided in dma_handle, and a kernel virtual address
> > that can be trivially generated.
>
> m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work
> on addresses returned by m8xx_cpm_hostalloc(). I just found that out the
> hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver

that's a problem with m8xx_cpm_hostalloc() (or how you are using it) if
it doesn't keep around the values you need.

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

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

Re: Regarding consistent_alloc

[Matt Porter]

On Fri, Dec 06, 2002 at 07:15:15PM +0100, Joakim Tjernlund wrote:
> >
> > On Fri, Dec 06, 2002 at 05:08:22PM +0100, Joakim Tjernlund wrote:
> > that's a problem with m8xx_cpm_hostalloc() (or how you are using it) if
> > it doesn't keep around the values you need.
> >
>
> Yes and no, someone changed the m8xx_cpm_hostalloc() implementation and now
> it does not behave as it used to. Earlier both __pa(adr) and __va(__pa(adr))
> worked on addresses returned by m8xx_cpm_hostalloc().
>
> I think in it's current form it's useless and should either be changed back to what
> it was or die.

The 8xx-specific stuff is clearly Dan's area...I was just commenting
on your generic concerns about consistent_*.

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

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

Re: Regarding consistent_alloc

[Dan Malek]

Matt Porter wrote:

> That's what I said...but you clipped it out.  Once again,
> consistent_alloc provides the caller everything they need.
> An uncached mapping, a phys address, and from that you can use
> __va() to get the cached mapping.

Well, in my defense.......I think you said you can use __va()
to get a kernel virtual address :-)  To further confuse thing,
yes it will give you a virtual address, but it isn't one that
you want to use.


> Seemed clear enough to me the first time.  My definition of a
> "kernel virtual address" is the lowmem cached mapping.

It wasn't clear to me, and "kernel virtual address" really can't
carry any other attributes since they are used to map a variety
of address spaces, including non-cached and highmem :-)  You
need to update your glossary :-)

Thanks.


	-- Dan


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

Re: Regarding consistent_alloc

[Dan Malek]

Joakim Tjernlund wrote:

> Yes and no, someone changed the m8xx_cpm_hostalloc() implementation and now
> it does not behave as it used to. Earlier both __pa(adr) and __va(__pa(adr))
> worked on addresses returned by m8xx_cpm_hostalloc().

I changed it a while back so single large pages could be used to map the
kernel space.  Just use iopa() on the virtual address to get the physical
address.  I don't understand the current condition of commproc.c today, but
I'm not the only one that updates it anymore.  The bk comments are quite
useless since all they indicate is some obscure patch was applied.

> I think in it's current form it's useless and should either be changed back to what
> it was or die.

It seems quite useful to the drivers that currently use it.........It's
only purpose is to provide small non-cached objects like uart fifos and control
areas.  Don't try to use it for things not intended.


	-- Dan


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

Re: Regarding consistent_alloc

[Joakim Tjernlund]

>
> Joakim Tjernlund wrote:
>
> > Yes and no, someone changed the m8xx_cpm_hostalloc() implementation and now
> > it does not behave as it used to. Earlier both __pa(adr) and __va(__pa(adr))
> > worked on addresses returned by m8xx_cpm_hostalloc().
>
> I changed it a while back so single large pages could be used to map the
> kernel space.  Just use iopa() on the virtual address to get the physical
> address.  I don't understand the current condition of commproc.c today, but
> I'm not the only one that updates it anymore.  The bk comments are quite
> useless since all they indicate is some obscure patch was applied.
>
> > I think in it's current form it's useless and should either be changed back to what
> > it was or die.
>
> It seems quite useful to the drivers that currently use it.........It's
> only purpose is to provide small non-cached objects like uart fifos and control
> areas.  Don't try to use it for things not intended.

Exacly, I was using it as a small fifo for my SPI driver(not really mine, I found it on the net).
Since  __pa() and __va() doesn't work anymore, it should be documented becauase I think
most people expect __pa() and __va() to work on kernel memory and it did work in 2.4.2.

Anyway, I have fixed my driver now so this is not a problem for me anymore.

 Jocke

PS.
   Dan, are you still working/testing my 8xx_io/enet.c patch?


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

RE: Regarding consistent_alloc

[Paul Mackerras]

Joakim Tjernlund writes:

> m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work
> on addresses returned by m8xx_cpm_hostalloc(). I just found that out the
> hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver
> hung as soon you tried to read something.

Then m8xx_cpm_hostalloc should be changed so it returns the DMA
address along with the virtual address (of the uncached mapping).

An alternative which will work, at least at present, is to use iopa()
on the virtual address.  However, that assumes that DMA bus addresses
are identical to CPU physical addresses.  That is true at the moment
on all embedded PPC platforms that I know of currently, but there is
no guarantee that it will always be true.  That is why I think it is
better to make a practice of saving the DMA address that you get back
from consistent_alloc and using that.

Paul.

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

Re: Regarding consistent_alloc

[Paul Mackerras]

Matt Porter writes:

> On Fri, Dec 06, 2002 at 11:56:22AM -0500, Dan Malek wrote:
> > Matt Porter wrote:
> >
> >  > ....  If you
> > > want the kernel virtual address then you can apply __va to that.
> >
> > Errr....no, you can't.  That would give you the cached mapping.
> > You need to hang on to both the dma_handle (the phys address token)
> > and the virtual address returned by the function.  That's why both
> > are returned.
>
> That's what I said...but you clipped it out.  Once again,
> consistent_alloc provides the caller everything they need.
> An uncached mapping, a phys address, and from that you can use
> __va() to get the cached mapping.

Matt, you know this I'm sure, but other people reading this might not:

You should NOT use the cached mapping unless you really know *exactly*
what you are doing.

The PowerPC architecture specifies that accessing a given physical
address through an uncached mapping, when there exists a copy of that
physical location in cache, is a programming error.  Different
implementations will do different things in this case.

> Seemed clear enough to me the first time.  My definition of a
> "kernel virtual address" is the lowmem cached mapping.  If
> I meant the uncached mapping I would have said it was a "kernel
> vmalloc address" or something. :)

A "kernel virtual address" is, to me (and to Dan as well, I expect),
any virtual address in the kernel portion of the address space
(i.e. above TASK_SIZE).  (Of course, you are free to adopt Humpty
Dumpty's attitude in Through the Looking Glass: "'When I use a word,
Humpty Dumpty said in rather a scornful tone, 'it means just what I
choose it to mean - neither more nor less.'" ;-)

Regards,
Paul.

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

Re: Regarding consistent_alloc

[Joakim Tjernlund]

> Joakim Tjernlund writes:
>
> > m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work
> > on addresses returned by m8xx_cpm_hostalloc(). I just found that out the
> > hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver
> > hung as soon you tried to read something.
>
> Then m8xx_cpm_hostalloc should be changed so it returns the DMA
> address along with the virtual address (of the uncached mapping).
>
> An alternative which will work, at least at present, is to use iopa()
> on the virtual address.  However, that assumes that DMA bus addresses
> are identical to CPU physical addresses.  That is true at the moment
> on all embedded PPC platforms that I know of currently, but there is
> no guarantee that it will always be true.  That is why I think it is
> better to make a practice of saving the DMA address that you get back
> from consistent_alloc and using that.

Is consistent_alloc really needed? All uses I have seen in the kernel for the 8xx CPU can be solved with
a kmalloc(or a static char buffer) and a invalidate_dcache_range call(flush_dcache_range if the buffer isn't cache line aligned).
This usally eliminates a memcpy() from uncached memory. See the 8xx_io/enet.c patch I sent to
this list a few weeks ago. One guy converted that patch to the 8260 FEC and had a 20% increase in performace
for big packets in his router.

    Jocke

PS.
     I still think the 'sync' instruction in invalidate_dcache_range is unneed. I have been running my system
     without it for a few weeks now and it still works as it should.

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

Re: Regarding consistent_alloc

[Dan Malek]

Joakim Tjernlund wrote:

> Is consistent_alloc really needed?

YES.

> .... All uses I have seen in the kernel for the 8xx CPU can be solved with
> a kmalloc....

The cpm_hostalloc() solves a different problem.  It is used to allocate
small non-cached object so you don't need the overhead of the cache
management functions every time you want to do something like write a byte
to a uart.  It is specific to the CPM on the 8xx, so you can apply the
proper assumptions about io mapping for a lightweight and efficient solution.

I've constantly criticized the Linux VM implementation for having different
functions and semantics for different VM spaces, and I'm always told something
to the effect "...it's the Linux way to make it efficient..."  So, I did
the same thing for 8xx and CPM.  There are lots of places in the Linux VM
where you can apply only certain operations to certain VM objects.  It
seems I've kept up the spirit :-)


	-- Dan


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

Re: Regarding consistent_alloc

[Pantelis Antoniou]

Paul Mackerras wrote:

>Joakim Tjernlund writes:
>
>
>>m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work
>>on addresses returned by m8xx_cpm_hostalloc(). I just found that out the
>>hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver
>>hung as soon you tried to read something.
>>
>
>Then m8xx_cpm_hostalloc should be changed so it returns the DMA
>address along with the virtual address (of the uncached mapping).
>
>An alternative which will work, at least at present, is to use iopa()
>on the virtual address.  However, that assumes that DMA bus addresses
>are identical to CPU physical addresses.  That is true at the moment
>on all embedded PPC platforms that I know of currently, but there is
>no guarantee that it will always be true.  That is why I think it is
>better to make a practice of saving the DMA address that you get back
>from consistent_alloc and using that.
>
>Paul.
>
>
>
>
>
Since I'm the one that started this thread let me make a few points.

1. The comment that consistent_alloc is tied to the PCI bus is valid,
since the dma_handle is returned by a call to virt_to_bus(), with
the virt_to_bus() being:

/*
 * The PCI bus is inherently Little-Endian.  The PowerPC is being
 * run Big-Endian.  Thus all values which cross the [PCI] barrier
 * must be endian-adjusted.  Also, the local DRAM has a different
 * address from the PCI point of view, thus buffer addresses also
 * have to be modified [mapped] appropriately.
 */
extern inline unsigned long virt_to_bus(volatile void * address)
{
#ifndef CONFIG_APUS
        if (address == (void *)0)
                return 0;
        return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;
#else
        return iopa ((unsigned long) address);
#endif
}

Also the consistent_sync() takes as a direction argument values like
PCI_DMA_FROMDEVICE.

It has something obviously to do with a PCI bus. My board, and I believe most of the boards with a 8xx do not have a PCI bus.

Is it possible to modify consistent_alloc to be something more
generic?

2. I have a requirement to have my drivers loaded as modules.
m8xx_cpm_hostalloc has a very simplistic implementation, which
makes it unsuitable for something like that. I have some patches
that fix both m8xx_cpm_hostalloc and 8xx_cpm_dpalloc by implementing
a proper heap, with free space management and coalescing.
What is the proper way to push them, and to whom?

3. I have already posted my QMC driver, and I'm in the process
of writting some documentation and usage scenarios.
Could someone please have a look and get back to me.
I'm open to suggestions, and I would very much like to have it
included in the tree.
I know it is not perfect but still as it stands there are no QMC
drivers in the tree.

Regards

--
Pantelis Antoniou
INTRACOM S.A. Greece


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

Re: Regarding consistent_alloc

[Tom Rini]

On Mon, Dec 09, 2002 at 11:06:13AM +0200, Pantelis Antoniou wrote:

[snip]
> Since I'm the one that started this thread let me make a few points.
>
> 1. The comment that consistent_alloc is tied to the PCI bus is valid,
> since the dma_handle is returned by a call to virt_to_bus(), with
> the virt_to_bus() being:
>
> /*
> * The PCI bus is inherently Little-Endian.  The PowerPC is being
> * run Big-Endian.  Thus all values which cross the [PCI] barrier
> * must be endian-adjusted.  Also, the local DRAM has a different
> * address from the PCI point of view, thus buffer addresses also
> * have to be modified [mapped] appropriately.
> */
> extern inline unsigned long virt_to_bus(volatile void * address)
> {
> #ifndef CONFIG_APUS
>        if (address == (void *)0)
>                return 0;
>        return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;
> #else
>        return iopa ((unsigned long) address);
> #endif
> }

This is typically used by PCI, but look at the code for the !CONFIG_APUS
(ie just about every machine, including all 8xx) case.  This is the
iopa, that if classes haven't made me even more incoherent, that has
been mentioned throught the thread.

> Also the consistent_sync() takes as a direction argument values like
> PCI_DMA_FROMDEVICE.

This is unfortunate, but 'expected' for now.  These constants really
have nothing to do with PCI DMA, but DMA in general.  There was a hope
of fixing that in 2.5, but I don't recall if it happened (it might
have) yet.

> It has something obviously to do with a PCI bus. My board, and I believe
> most of the boards with a 8xx do not have a PCI bus.
>
> Is it possible to modify consistent_alloc to be something more
> generic?

It is already generic, it's just not obvious :(

> 2. I have a requirement to have my drivers loaded as modules.
> m8xx_cpm_hostalloc has a very simplistic implementation, which
> makes it unsuitable for something like that. I have some patches
> that fix both m8xx_cpm_hostalloc and 8xx_cpm_dpalloc by implementing
> a proper heap, with free space management and coalescing.
> What is the proper way to push them, and to whom?

<buck passing mode=on>Dan Malek still knows the most about the
8xx-specific portions of the kernel, so he should really speak up here
when he gets a moment</buck passing>

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

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

RE: Regarding consistent_alloc

[acurtis]

> > 2. I have a requirement to have my drivers loaded as modules.
> > m8xx_cpm_hostalloc has a very simplistic implementation, which
> > makes it unsuitable for something like that. I have some patches
> > that fix both m8xx_cpm_hostalloc and 8xx_cpm_dpalloc by implementing
> > a proper heap, with free space management and coalescing.
> > What is the proper way to push them, and to whom?
>
> <buck passing mode=on>Dan Malek still knows the most about the
> 8xx-specific portions of the kernel, so he should really speak up here
> when he gets a moment</buck passing>

m8xx_cpm_hostalloc(), if it is anything like the 8260 version, enables you
to allocation memory from dual-port RAM. (which could be handy and/or
required for certain CPM related operations) _va() and _pa() only work for
main memory addresses. For all other address ranges the iopa() function must
be used. (I hope this is helpful)

With that said, I would be interested in your modifications if you are
willing to share.

THX


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

RE: Regarding consistent_alloc

[Joakim Tjernlund]

>
>
> > > 2. I have a requirement to have my drivers loaded as modules.
> > > m8xx_cpm_hostalloc has a very simplistic implementation, which
> > > makes it unsuitable for something like that. I have some patches
> > > that fix both m8xx_cpm_hostalloc and 8xx_cpm_dpalloc by implementing
> > > a proper heap, with free space management and coalescing.
> > > What is the proper way to push them, and to whom?

It would be great if the new fucntions could work with micropatch.c as well.
If the microcode is loaded, then those microcode area should be reserved and
not used by 8xx_cpm_dpalloc.

> >
> > <buck passing mode=on>Dan Malek still knows the most about the
> > 8xx-specific portions of the kernel, so he should really speak up here
> > when he gets a moment</buck passing>
>
> m8xx_cpm_hostalloc(), if it is anything like the 8260 version, enables you
> to allocation memory from dual-port RAM. (which could be handy and/or
> required for certain CPM related operations) _va() and _pa() only work for
> main memory addresses. For all other address ranges the iopa() function must
> be used. (I hope this is helpful)

_va() and _pa() used to work for m8xx_cpm_hostalloc() and I like that better. _pa()
is much cheaper than iopa() and there is no iova()(I think).

Why was m8xx_cpm_hostalloc() changed to use consistent_alloc()? alloc_bootmem_pages()
should still work(I am guessing)

BTW, m8xx_setup_arch() still calls alloc_bootmem_pages() and
the new m8xx_cpm_reset() does not take a ptr argument, but m8xx_setup_arch()
still calls m8xx_cpm_reset() with cpm_page as argument.

 Jocke

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

Re: Regarding consistent_alloc

[Pantelis Antoniou]

Joakim Tjernlund wrote:

>>
>>>>2. I have a requirement to have my drivers loaded as modules.
>>>>m8xx_cpm_hostalloc has a very simplistic implementation, which
>>>>makes it unsuitable for something like that. I have some patches
>>>>that fix both m8xx_cpm_hostalloc and 8xx_cpm_dpalloc by implementing
>>>>a proper heap, with free space management and coalescing.
>>>>What is the proper way to push them, and to whom?
>>>>
>
>It would be great if the new fucntions could work with micropatch.c as well.
>If the microcode is loaded, then those microcode area should be reserved and
>not used by 8xx_cpm_dpalloc.
>
As a matter of fact, this is another patch that I can submit
that take into account the area left by the micropatches so that the
dpalloc functions can utilize every last byte of the DPRAM.

At the moment I'm swamped with work, so it will take a couple of
days to clean things up and submit them.

>
>>><buck passing mode=on>Dan Malek still knows the most about the
>>>8xx-specific portions of the kernel, so he should really speak up here
>>>when he gets a moment</buck passing>
>>>
>>m8xx_cpm_hostalloc(), if it is anything like the 8260 version, enables you
>>to allocation memory from dual-port RAM. (which could be handy and/or
>>required for certain CPM related operations) _va() and _pa() only work for
>>main memory addresses. For all other address ranges the iopa() function must
>>be used. (I hope this is helpful)
>>
>
>_va() and _pa() used to work for m8xx_cpm_hostalloc() and I like that better. _pa()
>is much cheaper than iopa() and there is no iova()(I think).
>
>Why was m8xx_cpm_hostalloc() changed to use consistent_alloc()? alloc_bootmem_pages()
>should still work(I am guessing)
>
>BTW, m8xx_setup_arch() still calls alloc_bootmem_pages() and
>the new m8xx_cpm_reset() does not take a ptr argument, but m8xx_setup_arch()
>still calls m8xx_cpm_reset() with cpm_page as argument.
>
I think it's safe to assume that there is large amount of confussion at
this subject.
FWIW I dislike the use of iopa(), and I would be forced to duplicate the
code of
consistent_alloc() class of functions in my tree.

Could we at least have a m8xx_cpm_hostalloc that works as expected?
How about the following approach:

Each platform which is based on 8xx defines the amount of uncached
memory that is expected
to be used by it's drivers. It's not hard to make a rough estimation
since most people
that use the 8xx have very tight control of the hardware.
We organize then the memory in a heap, which is able to do allocations and
deallocations properly. That allows drivers that are loaded as modules
to operate
correctly and does not fragment (much) the memory.

How about it?

>
> Jocke
>
>
>
>

P.S. I have posted by QMC driver to the list, but there has been no
response.
Please if anyone is interested in the QMC, give me some kind of feedback.
Even negative feedback is OK.

Thanks

--
Pantelis Antoniou
INTRACOM S.A. Greece


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

RE: Regarding consistent_alloc

[acurtis]

> >>m8xx_cpm_hostalloc(), if it is anything like the 8260 version,
> enables you
> >>to allocation memory from dual-port RAM. (which could be handy and/or
> >>required for certain CPM related operations) _va() and _pa()
> only work for
> >>main memory addresses. For all other address ranges the iopa()
> function must
> >>be used. (I hope this is helpful)
> >>

snip

>
> Each platform which is based on 8xx defines the amount of uncached
> memory that is expected
> to be used by it's drivers. It's not hard to make a rough estimation
> since most people
> that use the 8xx have very tight control of the hardware.
> We organize then the memory in a heap, which is able to do allocations and
> deallocations properly. That allows drivers that are loaded as modules
> to operate
> correctly and does not fragment (much) the memory.

I almost missed the context change here... Changing xxx_cpm_hostalloc() to
be consistent with other main memory allocation routines would probably be a
good thing. However there is still a need to manage the dual-port RAM, i.e.
xxx_cpm_dpalloc(), where this requirement is probably not practical. The
only way to make this happen is to force all memory regions to be contiguous
both virtually and physically to enable the "simpler" address translation
routines to function properly.

As for a iova() routine, ioremap() will return a previously configured
virtual address when asked to map the same physical memory space.


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

Re: Regarding consistent_alloc

[Tom Rini]

On Wed, Dec 11, 2002 at 11:58:45AM +0200, Pantelis Antoniou wrote:

[snip]
> I think it's safe to assume that there is large amount of confussion at
> this subject.

Definatly.

> FWIW I dislike the use of iopa(), and I would be forced to duplicate the
> code of
> consistent_alloc() class of functions in my tree.

Why would you have to duplicate the consistent_alloc code?  It is not
tied to PCI, really.

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

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

Re: Regarding consistent_alloc

[Pantelis Antoniou]

acurtis@directvinternet.com wrote:

>>>>m8xx_cpm_hostalloc(), if it is anything like the 8260 version,
>>>>
>>enables you
>>
>>>>to allocation memory from dual-port RAM. (which could be handy and/or
>>>>required for certain CPM related operations) _va() and _pa()
>>>>
>>only work for
>>
>>>>main memory addresses. For all other address ranges the iopa()
>>>>
>>function must
>>
>>>>be used. (I hope this is helpful)
>>>>
>>>>
>
>snip
>
>
>>Each platform which is based on 8xx defines the amount of uncached
>>memory that is expected
>>to be used by it's drivers. It's not hard to make a rough estimation
>>since most people
>>that use the 8xx have very tight control of the hardware.
>>We organize then the memory in a heap, which is able to do allocations and
>>deallocations properly. That allows drivers that are loaded as modules
>>to operate
>>correctly and does not fragment (much) the memory.
>>
>
>I almost missed the context change here... Changing xxx_cpm_hostalloc() to
>be consistent with other main memory allocation routines would probably be a
>good thing. However there is still a need to manage the dual-port RAM, i.e.
>xxx_cpm_dpalloc(), where this requirement is probably not practical. The
>only way to make this happen is to force all memory regions to be contiguous
>both virtually and physically to enable the "simpler" address translation
>routines to function properly.
>
>As for a iova() routine, ioremap() will return a previously configured
>virtual address when asked to map the same physical memory space.
>
>
>
>
I'm sorry but I don't follow you there. The sole reason for the existance
of xxx_cpm_hostalloc() and xxx_cpm_dpalloc() is to provide support to
the drivers that deal with the CPM. I don't see why is there any need
to be consistent with any other allocation routines in the kernel.

Lets assume that we force the memory returned by the xxx_cpm_hostalloc()
and xxx_cpm_dpalloc() routines to return contiguous memory both
virtually and physically. Is there any negative impact?
Every driver out there expects precisely that.

Regarding the dual-ported memory, keep in mind that there are members
of the 8xx family that are very constrained.
Better allocation routines will allow us to utilise even the gaps
left between configured parameter areas. Yes it is horrible
but that's the way that the hardware is designed.

As I already mentioned, I have some patches that fix IMHO these
problems. Allow me some time to clean up and I will post them.

Regards

--
Pantelis Antoniou
INTRACOM S.A. Greece


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

Re: Regarding consistent_alloc

[Pantelis Antoniou]

Tom Rini wrote:

>On Wed, Dec 11, 2002 at 11:58:45AM +0200, Pantelis Antoniou wrote:
>
>[snip]
>
>>I think it's safe to assume that there is large amount of confussion at
>>this subject.
>>
>
>Definatly.
>
;)

>
>>FWIW I dislike the use of iopa(), and I would be forced to duplicate the
>>code of
>>consistent_alloc() class of functions in my tree.
>>
>
>Why would you have to duplicate the consistent_alloc code?  It is not
>tied to PCI, really.
>
Let's just say it's aesthetically unpleasent.
Since it is not tied to PCI anyway, what is the point
muddling it with it?

Perhaps the best way to proceed is just to fix the xxx_cpm_hostalloc() and
xxx_cpm_dpalloc() routines to work more intelligently, and to
forget about consistent_alloc entirely...

Regards

--
Pantelis Antoniou
INTRACOM S.A. Greece


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

RE: Regarding consistent_alloc

[acurtis]

> Lets assume that we force the memory returned by the xxx_cpm_hostalloc()
> and xxx_cpm_dpalloc() routines to return contiguous memory both
> virtually and physically. Is there any negative impact?
> Every driver out there expects precisely that.
>

It will be interesting to see how you solve the virtual and physical
contiguity in a general implementation. IMHO it isn't worth the effort.

> Regarding the dual-ported memory, keep in mind that there are members
> of the 8xx family that are very constrained.
> Better allocation routines will allow us to utilise even the gaps
> left between configured parameter areas. Yes it is horrible
> but that's the way that the hardware is designed.

Yes, we need every spare byte and sometime you MUST use certain memory
regions based on hardware contraints.

Sorry for any confusion.


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

Re: Regarding consistent_alloc

[Dan Malek]

acurtis@directvinternet.com wrote:

> As for a iova() routine, ioremap() will return a previously configured
> virtual address when asked to map the same physical memory space.

No, it does not.  The ioremap() may do this in some cases on processors
that use BATs for large space mapping, but it usually (always on 8xx)
allocates new virtual space when mapping a physical address.


	-- Dan


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

Re: Regarding consistent_alloc

[Dan Malek]

Pantelis Antoniou wrote:

> Perhaps the best way to proceed is just to fix the xxx_cpm_hostalloc() and
> xxx_cpm_dpalloc() routines to work more intelligently, and to
> forget about consistent_alloc entirely...

You are totally missing the proper use of these functions.  The 'cpm'
functions are used specifically to assist the management of memory
for the CPM peripherals on the 8xx and 82xx processor.  There are often
unique attributes of mapping these spaces that must be considered.  The
only thing to "fix" in these functions is to make a resource free (and
smarter resource management) that works for loadable modules.

The purpose of consistent_alloc() functions is to provide a method of
allocating DMA consistent (i.e. non-cached in our case) memory spaces
for _any_ purpose.  These are functions you will find in other processor
architectures and have become standard part of many Linux processor ports.

The 'cpm' and PCI (and other non-PCI functions like USB OHCI) functions
will rely on the consistent_alloc() functions to provide consistent
spaces when necessary.  There are some memory mapping assumptions made
about the way consistent memory is allocated for the purposes of portabilty
and performance.

All of these functions are required and work reasonably well as currently
implemented when they are used properly.

Thanks.


	-- Dan


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

Re: Regarding consistent_alloc

[Pantelis Antoniou]

Dan Malek wrote:

> Pantelis Antoniou wrote:
>
>> Perhaps the best way to proceed is just to fix the
>> xxx_cpm_hostalloc() and
>> xxx_cpm_dpalloc() routines to work more intelligently, and to
>> forget about consistent_alloc entirely...
>
>
> You are totally missing the proper use of these functions.  The 'cpm'
> functions are used specifically to assist the management of memory
> for the CPM peripherals on the 8xx and 82xx processor.  There are often
> unique attributes of mapping these spaces that must be considered.  The
> only thing to "fix" in these functions is to make a resource free (and
> smarter resource management) that works for loadable modules.
>
> The purpose of consistent_alloc() functions is to provide a method of
> allocating DMA consistent (i.e. non-cached in our case) memory spaces
> for _any_ purpose.  These are functions you will find in other processor
> architectures and have become standard part of many Linux processor
> ports.
>
> The 'cpm' and PCI (and other non-PCI functions like USB OHCI) functions
> will rely on the consistent_alloc() functions to provide consistent
> spaces when necessary.  There are some memory mapping assumptions made
> about the way consistent memory is allocated for the purposes of
> portabilty
> and performance.
>
> All of these functions are required and work reasonably well as currently
> implemented when they are used properly.
>
> Thanks.
>
>
>     -- Dan
>
>
>

Fine,

I see now.

Since what I'm doing regards the CPM the proper thing to do
is to actually use the 8xx routines.

They only reason that I considered the consistent() routines was
that the 8xx routines are unsuitable for use in modules.

I will prepare a patch that deals with the inefficiencies
of the 8xx routines.

I believe you are the person that is assigned for maintaining
the 8xx series. Can you audit them after I post them
to the list?

Regards

--
Pantelis Antoniou
INTRACOM S.A. Greece


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

Re: Regarding consistent_alloc

[Wolfgang Denk]

In message <3DF8420A.4040409@intracom.gr> you wrote:
>
> They only reason that I considered the consistent() routines was
> that the 8xx routines are unsuitable for use in modules.

This  is  trivial  to  fix  -  just  add  the  missing  EXPORT_SYMBOL
statements  to  arch/ppc/kernel/ppc_ksyms.c  ;  but be aware that the
current implementation will leak CPM resources upon module  unload  -
which  is probably the main reason that these symbols are not expoted
for use in modules.

> I will prepare a patch that deals with the inefficiencies
> of the 8xx routines.

Don't re-invent the wheel. There is an implementation  of  this  code
available  in  our  kernel  source tree (linux-2.4 module in our CVS)
which for example provides both m8xx_cpm_dpalloc / m8xx_cpm_dpfree

I sent the patches to Tom Rini. Several times. I don't know why  they
never  made  it into the official kernel source tree. [This is why we
have to maintain our own source tree.]


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The C-shell doesn't parse. It adhoculates.
    - Casper.Dik@Holland.Sun.COM in <3ol96k$b2j@engnews2.Eng.Sun.COM>

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

Re: Regarding consistent_alloc

[Pantelis Antoniou]

Wolfgang Denk wrote:

>In message <3DF8420A.4040409@intracom.gr> you wrote:
>
>
>>They only reason that I considered the consistent() routines was
>>that the 8xx routines are unsuitable for use in modules.
>>
>>
>
>This  is  trivial  to  fix  -  just  add  the  missing  EXPORT_SYMBOL
>statements  to  arch/ppc/kernel/ppc_ksyms.c  ;  but be aware that the
>current implementation will leak CPM resources upon module  unload  -
>which  is probably the main reason that these symbols are not expoted
>for use in modules.
>
Yes I know, that is one the main deficiencies I'm talking about...

>
>>I will prepare a patch that deals with the inefficiencies
>>of the 8xx routines.
>>
>>
>
>Don't re-invent the wheel. There is an implementation  of  this  code
>available  in  our  kernel  source tree (linux-2.4 module in our CVS)
>which for example provides both m8xx_cpm_dpalloc / m8xx_cpm_dpfree
>
>I sent the patches to Tom Rini. Several times. I don't know why  they
>never  made  it into the official kernel source tree. [This is why we
>have to maintain our own source tree.]
>
>
>Best regards,
>
>Wolfgang Denk
>
Could you please sent me these patches, since I'm behind a firewall?

But still there is the matter of the m8xx_cpm_hostalloc routines.

BTW Wolfgang have you seen my patch for the QMC? Any comments?
Please note that I had a few requests for the QMC patch directly
by people off the list, so it's not like no-one is using it...

Regards

--
Pantelis Antoniou
INTRACOM S.A. Greece


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

Is the preemptive kernel patch unsafe for 8xx/PPC?

[Joakim Tjernlund]

Hi all

I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?

So far it boots and runs fine but that's no proof.

    Jocke

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

"Missing" patches (Was: Re: Regarding consistent_alloc)

[Tom Rini]

On Thu, Dec 12, 2002 at 09:18:36AM +0100, Wolfgang Denk wrote:

> I sent the patches to Tom Rini. Several times. I don't know why  they
> never  made  it into the official kernel source tree. [This is why we
> have to maintain our own source tree.]

I believe part of the reason is in the list archives somewhere.  If you
can't recall or find exactly why feel free to shoot me an email privately
and I'll remind you.

However, if you're willing to forget about it all and start over, and
will submit changes in the form of a patch which makes only one logical
change at a time, vs linuxppc_2_4 and linuxppc-2.5 trees, I will happily
review and comment or apply patches starting the week of 12/23 (since
I have finals up to and including 12/20).

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

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

Re: Is the preemptive kernel patch unsafe for 8xx/PPC?

[Eugene Surovegin]

At 04:56 AM 12/12/2002, you wrote:
>I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
>I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?

I haven't tested patch for 2.4.20 but patch for 2.4.19 contained some bugs.


  Eugene Surovegin <mailto:ebs@innocent.com>


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

Re: Is the preemptive kernel patch unsafe for 8xx/PPC?

[Joakim Tjernlund]

Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?

According to the message Robert posted on lkm is the 2.4.20-1 patch only a
rediff of the latest 2.4.19 patch.

BTW, I am on the 2_4_devel branch.

   Jocke

> At 04:56 AM 12/12/2002, you wrote:
> >I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
> >I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?
>
> I haven't tested patch for 2.4.20 but patch for 2.4.19 contained some bugs.
>
>
>   Eugene Surovegin <mailto:ebs@innocent.com>
>

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

RE: Is the preemptive kernel patch unsafe for 8xx/PPC?

[acurtis]

Can you be more specific about the "bugs". I just installed the patch. The
patch did not apply cleanly. Is this what you are referring to? It was
simple to fix the rejects.

THX

> -----Original Message-----
> From: owner-linuxppc-dev@lists.linuxppc.org
> [mailto:owner-linuxppc-dev@lists.linuxppc.org]On Behalf Of Eugene
> Surovegin
> Sent: Thursday, December 12, 2002 10:28 AM
> To: joakim.tjernlund@lumentis.se
> Cc: linuxppc-dev@lists.linuxppc.org
> Subject: Re: Is the preemptive kernel patch unsafe for 8xx/PPC?
>
>
>
> At 04:56 AM 12/12/2002, you wrote:
> >I am testing the latest(2.4.20-1) preemtive kernel patch from
> Robert Love and
> >I wonder if anybody know if it's unsafe/not working for 8xx or
> PPC in general?
>
> I haven't tested patch for 2.4.20 but patch for 2.4.19 contained
> some bugs.
>
>
>   Eugene Surovegin <mailto:ebs@innocent.com>
>
>
>
>
>


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

RE: Is the preemptive kernel patch unsafe for 8xx/PPC?

[acurtis]

The patch did not apply cleanly for me using linuxppc_2_4_devel, BK label
2.4.19 final.
The following files got rejected:
	include/asm-ppc/dma.h
	include/asm-ppc/pgtable.h

It was very straight forward to apply the patches by hand. The line numbers
were a bit off.

>
> Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?
>
> According to the message Robert posted on lkm is the 2.4.20-1 patch only a
> rediff of the latest 2.4.19 patch.
>
> BTW, I am on the 2_4_devel branch.


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

Re: Is the preemptive kernel patch unsafe for 8xx/PPC?

[Eugene Surovegin]

Joakim,

At 12:35 PM 12/12/2002, you wrote:
>Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?

I had the following issues with 2.4.19-2 (2.4.20-1 is identical in this
regard):

1) arch/ppc/kernel.entry.S

diff -urN linux-2.4.20/arch/ppc/kernel/entry.S linux/arch/ppc/kernel/entry.S
--- linux-2.4.20/arch/ppc/kernel/entry.S        2002-11-28
18:53:11.000000000 -0500
+++ linux/arch/ppc/kernel/entry.S       2002-12-11 02:34:47.000000000 -0500
@@ -278,6 +278,41 @@
          */
         cmpi    0,r3,0
         beq     restore
+#ifdef CONFIG_PREEMPT
+       lwz     r3,PREEMPT_COUNT(r2)
+       cmpi    0,r3,1
+       bge     ret_from_except
+       lwz     r5,_MSR(r1)
+       andi.   r5,r5,MSR_PR
+       bne     do_signal_ret

     <rest of the diff is skipped>

I had to change the last command to "bne ret_from_except".
I checked MontaVista tree, and they have "ret_from_except" there also.

Without this change trivial code:

   while (true) ;

locked the box completely.

2) include/asm-ppc/pgalloc.h  There are curly brackets missing in
get_pgd_fast()

3) to support 440GP you have to modify arc/ppc/kernel/irc.c:preempt_intercept:

#if !defined(CONFIG_4xx) || defined(CONFIG_440)
         case 0x900:
#else
         case 0x1000:
#endif

With these changes (an maybe some others I forgot to mention here :),
I have pretty stable preemptable kernel (2.4.19, PPC440GP & 405GP, also
with rtsched patch by George Anzinger)

Thanks,


  Eugene Surovegin <mailto:ebs@innocent.com>


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

RE: Is the preemptive kernel patch unsafe for 8xx/PPC?

[Joakim Tjernlund]

Hi Eugene

> From: Eugene Surovegin [mailto:ebs@innocent.com]
> Joakim,
>
> At 12:35 PM 12/12/2002, you wrote:
> >Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?
>
> I had the following issues with 2.4.19-2 (2.4.20-1 is identical in this
> regard):
>
> 1) arch/ppc/kernel.entry.S
>
> diff -urN linux-2.4.20/arch/ppc/kernel/entry.S linux/arch/ppc/kernel/entry.S
> --- linux-2.4.20/arch/ppc/kernel/entry.S        2002-11-28
> 18:53:11.000000000 -0500
> +++ linux/arch/ppc/kernel/entry.S       2002-12-11 02:34:47.000000000 -0500
> @@ -278,6 +278,41 @@
>           */
>          cmpi    0,r3,0
>          beq     restore
> +#ifdef CONFIG_PREEMPT
> +       lwz     r3,PREEMPT_COUNT(r2)
> +       cmpi    0,r3,1
> +       bge     ret_from_except
> +       lwz     r5,_MSR(r1)
> +       andi.   r5,r5,MSR_PR
> +       bne     do_signal_ret
>
>      <rest of the diff is skipped>
>
> I had to change the last command to "bne ret_from_except".
> I checked MontaVista tree, and they have "ret_from_except" there also.

This I can not comment on, but my 8xx runs fine with it.

>
> Without this change trivial code:
>
>    while (true) ;
>
> locked the box completely.
>
> 2) include/asm-ppc/pgalloc.h  There are curly brackets missing in
> get_pgd_fast()

Yes, they are missing in the else part.

>
> 3) to support 440GP you have to modify arc/ppc/kernel/irc.c:preempt_intercept:
>
> #if !defined(CONFIG_4xx) || defined(CONFIG_440)
>          case 0x900:
> #else
>          case 0x1000:
> #endif

OK, this does not affect 8xx so this I can not test.

>
> With these changes (an maybe some others I forgot to mention here :),
> I have pretty stable preemptable kernel (2.4.19, PPC440GP & 405GP, also
> with rtsched patch by George Anzinger)
>
Can you run the above changes by Robert Love so he can comment/update the patch?

 Jocke

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

RE: Is the preemptive kernel patch unsafe for 8xx/PPC?

[acurtis]

I ran this patch on 2.4.19 and here were my results.

> > 1) arch/ppc/kernel.entry.S
> >
> > diff -urN linux-2.4.20/arch/ppc/kernel/entry.S
> linux/arch/ppc/kernel/entry.S
> > --- linux-2.4.20/arch/ppc/kernel/entry.S        2002-11-28
> > 18:53:11.000000000 -0500
> > +++ linux/arch/ppc/kernel/entry.S       2002-12-11
> 02:34:47.000000000 -0500
> > @@ -278,6 +278,41 @@
> >           */
> >          cmpi    0,r3,0
> >          beq     restore
> > +#ifdef CONFIG_PREEMPT
> > +       lwz     r3,PREEMPT_COUNT(r2)
> > +       cmpi    0,r3,1
> > +       bge     ret_from_except
> > +       lwz     r5,_MSR(r1)
> > +       andi.   r5,r5,MSR_PR
> > +       bne     do_signal_ret
> >
> >      <rest of the diff is skipped>
> >
> > I had to change the last command to "bne ret_from_except".
> > I checked MontaVista tree, and they have "ret_from_except" there also.
>
> This I can not comment on, but my 8xx runs fine with it.

I did not make the above code change and it appears to run. Any comments?

> > 2) include/asm-ppc/pgalloc.h  There are curly brackets missing in
> > get_pgd_fast()
>
> Yes, they are missing in the else part.

I had to fix this too.

> > 3) to support 440GP you have to modify
> arc/ppc/kernel/irc.c:preempt_intercept:
> >
> > #if !defined(CONFIG_4xx) || defined(CONFIG_440)
> >          case 0x900:
> > #else
> >          case 0x1000:
> > #endif

I could not test these changes either. Any feedback from Robert Love?

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