While compiling the current kernel on prep ppc:
MODPOST 703 modules
ERROR: copy_page [fs/fuse/fuse.ko] undefined!
ERROR: empty_zero_page [fs/ext4/ext4dev.ko] undefined!
--
Meelis Roos ([EMAIL PROTECTED])
___
Linuxppc-dev mailing list
On Tue, 27 May 2008, Linus Torvalds wrote:
Here's a UNTESTED patch for x86 that may or may not compile and work, and
which serializes (on a compiler level) the IO accesses against regular
memory accesses.
Ok, so it at least boots on x86-32. Thus probably on x86-64 too (since the
code is
On Tue, 2008-05-27 at 08:50 -0700, Roland Dreier wrote:
Though it's my understanding that at least ia64 does require the
explicit barriers anyway, so we are still in a dodgy situation here
where it's not clear what drivers should do and we end up with
possibly excessive barriers on
Actually, this specifically should not be. The need for mmiowb on altix
is because it explicitly violates some of the PCI rules that would
otherwise impede performance. The compromise is that readX on altix
contains the needed dma flush but there's a variant operator,
readX_relaxed
On Tue, 2008-05-27 at 10:38 -0700, Roland Dreier wrote:
Actually, this specifically should not be. The need for mmiowb on altix
is because it explicitly violates some of the PCI rules that would
otherwise impede performance. The compromise is that readX on altix
contains the needed
Kumar Gala wrote:
On Feb 25, 2008, at 6:39 PM, David Gibson wrote:
On Wed, Feb 20, 2008 at 01:19:41PM -0600, Scott Wood wrote:
A property's data can be populated with a file's contents
as follows:
node {
prop = /incbin/(path/to/data);
};
A subset of a file can be included by passing
I have tried the latest code and now, I'm able to
write a limited amount. After which when I reboot,
more than 100 contiguous blocks have been marked bad,
through the end of the device (according to the dts).
Is this something that has been seen before? My NAND
device is a large page.
Ron
---
Ron Madrid wrote:
I have tried the latest code and now, I'm able to
write a limited amount. After which when I reboot,
more than 100 contiguous blocks have been marked bad,
through the end of the device (according to the dts).
Is this something that has been seen before?
Yes, but not with
Um, OK, you've said write twice now ... I was assuming you meant read.
Even on an x86, writes are posted, so there's no way a spin lock could
serialise a write without an intervening read to flush the posting
(that's why only reads have a relaxed version on altix). Or is there
something
Writes are posted yes, but not reordered arbitrarily.
on standard x86 I mean here...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Tue, 27 May 2008, Linus Torvalds wrote:
On Tue, 27 May 2008, Benjamin Herrenschmidt wrote:
Yes. As it is today, tg3 for example is potentially broken on all archs
with newer gcc unless we either add memory clobber to readl/writel or
stick some wmb's in there (just a random driver I picked).
Trent Piepho wrote:
Is there an issue with anything _besides_ coherent DMA?
Could one have a special version of the accessors for drivers that
want to assume they are strictly ordered vs coherent DMA memory?
That would be much easier to get right, without slowing _everything_
down.
It's
In which function should I start searching for this
problem? What would cause a block to be marked bad?
Ron
--- Scott Wood [EMAIL PROTECTED] wrote:
Ron Madrid wrote:
I have tried the latest code and now, I'm able to
write a limited amount. After which when I
reboot,
more than 100
Ron Madrid wrote:
In which function should I start searching for this
problem? What would cause a block to be marked bad?
No particular function; just something that causes things to not work. :-P
You may want to try increasing the OR[SCY] field or other timing
parameters associated with
On Tue, 2008-05-27 at 08:35 -0700, Linus Torvalds wrote:
On Tue, 27 May 2008, Benjamin Herrenschmidt wrote:
Yes. As it is today, tg3 for example is potentially broken on all archs
with newer gcc unless we either add memory clobber to readl/writel or
stick some wmb's in there (just a
On Tue, 2008-05-27 at 08:50 -0700, Roland Dreier wrote:
Though it's my understanding that at least ia64 does require the
explicit barriers anyway, so we are still in a dodgy situation here
where it's not clear what drivers should do and we end up with
possibly excessive barriers on
On Tue, 2008-05-27 at 09:47 -0700, Linus Torvalds wrote:
__read[bwlq]()/__write[bwlq]() are not serialized with a :memory
barrier, although since they still use asm volatile I suspect that
i
practice they are probably serial too. Did not look very closely at
any
generated code (only
Roland Dreier wrote:
Writes are posted yes, but not reordered arbitrarily. If I have code like:
spin_lock(mmio_lock);
writel(val1, reg1);
writel(val2, reg2);
spin_unlock(mmio_lock);
then I have a reasonable expectation that if two CPUs run this at the
same
Writes are posted yes, but not reordered arbitrarily. If I have code like:
spin_lock(mmio_lock);
writel(val1, reg1);
writel(val2, reg2);
spin_unlock(mmio_lock);
then I have a reasonable expectation that if two CPUs run this at the
same time, their writes to
On Wed, 28 May 2008, Benjamin Herrenschmidt wrote:
On Tue, 2008-05-27 at 08:35 -0700, Linus Torvalds wrote:
Expecting people to fix up all drivers is simply not going to happen. And
serializing things shouldn't be *that* expensive. People who cannot take
the expense can continue to
Kumar was just mentioning this post a few messages ago:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/055745.html
That is a very interesting approach to handle all the differences
between each processor's architecture, and a much cleaner way to set the
facilities we want than the
This is a different issue. We deal with it on powerpc by having writel
set a per-cpu flag and spin_unlock() test it, and do the barrier if
needed there.
Cool... I assume you do this for mutex_unlock() etc?
Is there any reason why ia64 can't do this too so we can kill mmiowb and
save
So practically speaking, I suspect that the right approach is to just say
ok, x86 will continue to be pretty darn ordered, and the barriers won't
really matter (*) but at the same time also saying we wish reality was
different, and well-maintained drivers should probably try to work in the
re-ordering, even though I doubt it will be visible in practice. So if you
use the __ versions, you'd better have barriers even on x86!
Are we also going to have __ioread*/__iowrite* ?
Also is the sematics of __readl/__writel defined for all architectures -
I used it ages ago in the i2o
On Tue, May 27, 2008 at 10:38:22PM +0100, Alan Cox wrote:
re-ordering, even though I doubt it will be visible in practice. So if you
use the __ versions, you'd better have barriers even on x86!
Are we also going to have __ioread*/__iowrite* ?
Didn't we already define ioread*() to have
On Wed, 28 May 2008, Benjamin Herrenschmidt wrote:
A problem with __raw_ though is that they -also- don't do byteswap,
Well, that's why there is __readl() and __raw_readl(), no?
Neither does ordering, and __raw_readl() doesn't do byte-swap.
Of course, I'm not going to guarantee every
On Tue, 27 May 2008, Alan Cox wrote:
re-ordering, even though I doubt it will be visible in practice. So if you
use the __ versions, you'd better have barriers even on x86!
Are we also going to have __ioread*/__iowrite* ?
I doubt there is any reason to. Let's just keep them very
On Tue, 27 May 2008 15:53:28 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Tue, May 27, 2008 at 10:38:22PM +0100, Alan Cox wrote:
re-ordering, even though I doubt it will be visible in practice. So if
you
use the __ versions, you'd better have barriers even on x86!
Are we also
On Tue, 27 May 2008, Matthew Wilcox wrote:
On Tue, May 27, 2008 at 10:38:22PM +0100, Alan Cox wrote:
re-ordering, even though I doubt it will be visible in practice. So if
you
use the __ versions, you'd better have barriers even on x86!
Are we also going to have
On Wed, May 28, 2008 at 07:38:55AM +1000, Benjamin Herrenschmidt wrote:
A problem with __raw_ though is that they -also- don't do byteswap,
which is a pain in the neck as people use them for either one reason
(relaxed ordering) or the other (no byteswap) without always knowing the
consequences
On Tue, 2008-05-27 at 14:33 -0700, Roland Dreier wrote:
This is a different issue. We deal with it on powerpc by having writel
set a per-cpu flag and spin_unlock() test it, and do the barrier if
needed there.
Cool... I assume you do this for mutex_unlock() etc?
That's a good point...
On Tue, 2008-05-27 at 15:42 -0600, Matthew Wilcox wrote:
On Wed, May 28, 2008 at 07:38:55AM +1000, Benjamin Herrenschmidt wrote:
A problem with __raw_ though is that they -also- don't do byteswap,
which is a pain in the neck as people use them for either one reason
(relaxed ordering) or
Cool... I assume you do this for mutex_unlock() etc?
That's a good point... I don't think we do. Maybe we should.
I think it's needed -- take a look at 76d7cc03, which came from a real
bug seen on Altix boxes.
___
Linuxppc-dev mailing list
Chris Friesen writes:
Roland Dreier wrote:
Writes are posted yes, but not reordered arbitrarily. If I have code like:
spin_lock(mmio_lock);
writel(val1, reg1);
writel(val2, reg2);
spin_unlock(mmio_lock);
then I have a reasonable expectation that if two CPUs
Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated
for the in_beXX() and out_beXX() mmio functions has been sub-optimal.
The out_leXX() family of functions are created with the macro
DEF_MMIO_OUT_LE() while the out_beXX() family are created with
DEF_MMIO_OUT_BE(). In what
gcc might re-order MMIO accessors vs. surrounding consistent
memory accesses, which is a bad thing.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
include/asm-powerpc/io.h | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
---
Currently ext4 and fuse fail to link if modular:
ERROR: copy_page [fs/fuse/fuse.ko] undefined!
ERROR: empty_zero_page [fs/ext4/ext4dev.ko] undefined!
make[3]: *** [__modpost] Error 1
make[2]: *** [modules] Error 2
make[1]: *** [sub-make] Error 2
While arch ppc exists it may as well compile.
On Tue, May 27, 2008 at 08:25:43PM +0300, Meelis Roos wrote:
While compiling the current kernel on prep ppc:
MODPOST 703 modules
ERROR: copy_page [fs/fuse/fuse.ko] undefined!
ERROR: empty_zero_page [fs/ext4/ext4dev.ko] undefined!
Try that patch at:
I'm playing around with a Alsa SOC driver for the Efika. The Efika
uses a STAC9266 for AC97 which supports simultaneous SPDIF and analog
output. To do this the PSC needs DMA data from two different buffers
interleaved and placed into its FIFO. Is this something Bestcomm can
do?
Examples
mono +
39 matches
Mail list logo
