RE: switching linux kernels

Hello,
In 2.2.14, I need to have the Copy-Back Data Cache option off for my drivers
to work with video, same as in 2.2.13, or I else I get corrupted video data.
I guess, in my case this is good because video data will never be the same.
Thanks again for the help. My 2.2.14 kernel seems to be working just fine.
--Julia


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

Julia Elbert writes:

In 2.2.14, I need to have the Copy-Back Data Cache option off for my drivers
to work with video, same as in 2.2.13, or I else I get corrupted video data.

Turning off copy-back has a global performance hit, so it's a pretty nasty
workaround for cache coherency bugs in a single driver.  It's OK when it gets
you going in a pinch, but as you've found, these bugs keep coming back to bite
every time you upgrade to a more aggressive caching regimen.  Also, perhaps
your driver isn't doing I/O barrier stuff properly; does it use insx/outsx &
friends from asm/io.h, or does it dereference pointers directly, forgetting
the eieio's?

Regards,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

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

Graham Stoney wrote:

Turning off copy-back has a global performance hit, so it's a pretty nasty
workaround for cache coherency bugs in a single driver.

Yep, you should really fix the driver.....

....... does it use insx/outsx &
friends from asm/io.h, or does it dereference pointers directly, forgetting
the eieio's?

Please don't use in/out macros on PowerPC....especially on 8xx their
underlying address arithmetic will likely break more things that it
fixes.
Use memory mapped I/O (readb/writeb, etc.) and ioremap().....


	-- Dan

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

Dan Malek writes:

Use memory mapped I/O (readb/writeb, etc.) and ioremap().....

Err, yes.  That's what I meant to say, had I been thinking straight :-).
Only realised my goof after hitting "send"...

Regards,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

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

Please don't use in/out macros on PowerPC....especially on 8xx their
underlying address arithmetic will likely break more things that it
fixes.
Use memory mapped I/O (readb/writeb, etc.) and ioremap().....

presumably this is due to int in/out macros adding _IO_BASE to the pointer? So
am I right in thinking that it makes sense to use in/out for ISA accesses (if
_IO_BASE is set correctly for your platform) and readb/writeb/.. for the rest of
your memory mapped registers?

Thanks,
Rob Taylor
Flying Pig Systems


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

Rob Taylor wrote:

presumably this is due to int in/out macros adding _IO_BASE to the pointer?

Yes.

... So
am I right in thinking that it makes sense to use in/out for ISA accesses (if
_IO_BASE is set correctly for your platform) and readb/writeb/.. for the rest of
your memory mapped registers?

Well, yes, today.  Some of us have been "fighting" about this lately.
I'm not a fan of address arithmetic in the inb/outb, so probably on
8xx and 82xx you will always have some "opaque" handle to in/out that
doesn't resemble any notion of x86 "ports".  The reason is that on
these 8xx and 82xx systems (and potentially others) we don't have very
flexible host bridges, or the processors are used in complex multiple
PCI bus configurations where the notion of "bus 0" may not exist.  You
can't assume using a hard coded (or legacy) port number will get you
anywhere but a bus fault.


	-- Dan

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

I was just having a second look at io.h, cos i'm using a hacked up version for
some ppcboot stuff, and I noticed that when CONFIG_APUS is on read doesn't
eieio, and when its on it does, surely readw/writew, etc shouldn't eieio and
in/out, etc should? infact the whole thing seems a bit of a mess.
attached are the functions I'm using for pci accesses in ppcboot. Doubt it'll be
of any use, but I thought you might be interested.


Thanks,
Rob Taylor
Flying Pig Systems

quoted

presumably this is due to int in/out macros adding _IO_BASE to the pointer?

Yes.

quoted

... So
am I right in thinking that it makes sense to use in/out for ISA

accesses (if

quoted

_IO_BASE is set correctly for your platform) and readb/writeb/..

for the rest of

quoted

your memory mapped registers?

Well, yes, today.  Some of us have been "fighting" about this lately.
I'm not a fan of address arithmetic in the inb/outb, so probably on
8xx and 82xx you will always have some "opaque" handle to in/out that
doesn't resemble any notion of x86 "ports".  The reason is that on
these 8xx and 82xx systems (and potentially others) we don't have very
flexible host bridges, or the processors are used in complex multiple
PCI bus configurations where the notion of "bus 0" may not exist.  You
can't assume using a hard coded (or legacy) port number will get you
anywhere but a bus fault.


	-- Dan