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 + spd
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: http://patchwork.ozlabs.org/linu
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.
S
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(-)
--- linux-work.orig/include/asm-power
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 wa
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
> > 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
Linux
On Tue, 2008-05-27 at 14:55 -0700, Linus Torvalds wrote:
>
> 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?
As I replied to somebody else, __readl() is
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)
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 po
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
> consequen
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 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!
> >
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 ver
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 arch
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 h
> 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 dr
> 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
> 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 ever
> 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 c
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 co
> > 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 tim
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 ti
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 cod
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 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 ther
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 the
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
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 better
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)
> 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
> 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
> somet
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 the
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
--- S
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 s
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 n
> 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_relaxe
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 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
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
Linuxppc-dev
40 matches
Mail list logo
