RE: switching linux kernels

RE: switching linux kernels

[Julia Elbert]

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/

Re: switching linux kernels

[Graham Stoney]

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/

Re: switching linux kernels

[Dan Malek]

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/

Re: switching linux kernels

[Graham Stoney]

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/

RE: switching linux kernels

[Rob Taylor]

> 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/

Re: switching linux kernels

[Dan Malek]

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/

RE: switching linux kernels

[Rob Taylor]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

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

>
> > 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
>
>

[-- Attachment #2: pci_io.h --]
[-- Type: application/octet-stream, Size: 2473 bytes --]

/* originally from linux source (asm-ppc/io.h).
 * Sanity added by Rob Taylor, Flying Pig Systems, 2000
 */
#ifndef _PCI_IO_H_
#define _PCI_IO_H_

#include <io.h>

#define pcimem_readb(addr) (*(volatile u8 *) (addr))
#define pcimem_writeb(b,addr) ((*(volatile u8 *) (addr)) = (b))
#define pciio_readb(addr) (*(volatile u8 *) (addr)); eieio()
#define pciio_writeb(b,addr) ((*(volatile u8 *) (addr)) = (b)); eieio()

#if !defined(__BIG_ENDIAN)
#define pcimem_readw(addr) (*(volatile u16 *) (addr))
#define pcimem_readl(addr) (*(volatile u32 *) (addr))
#define pcimem_writew(b,addr) ((*(volatile u16 *) (addr)) = (b))
#define pcimem_writel(b,addr) ((*(volatile u32 *) (addr)) = (b))
#else
#define pcimem_readw(addr) pcimem_read_le16((volatile u16 *)(addr))
#define pcimem_readl(addr) pcimem_read_le32((volatile u32 *)(addr))
#define pcimem_writew(b,addr) pcimem_write_le16((volatile u16 *)(addr),(b))
#define pcimem_writel(b,addr) pcimem_write_le32((volatile u32 *)(addr),(b))
#endif

#if !defined(__BIG_ENDIAN)
#define pciio_readw(addr) (*(volatile u16 *) (addr)); eieio()
#define pciio_readl(addr) (*(volatile u32 *) (addr)); eieio()
#define pciio_writew(b,addr) ((*(volatile u16 *) (addr)) = (b)); eieio()
#define pciio_writel(b,addr) ((*(volatile u32 *) (addr)) = (b)); eieio()
#else
#define pciio_readw(addr) pcimem_read_le16((volatile u16 *)(addr)); eieio()
#define pciio_readl(addr) pcimem_read_le32((volatile u32 *)(addr)); eieio()
#define pciio_writew(b,addr) pcimem_write_le16((volatile u16 *)(addr),(b)); eieio()
#define pciio_writel(b,addr) pcimem_write_le32((volatile u32 *)(addr),(b)); eieio()
#endif

extern inline int pcimem_read_le16(volatile unsigned short *addr)
{
    int ret;

    __asm__ __volatile__("lhbrx %0,0,%1" : "=r" (ret) :
                  "r" (addr), "m" (*addr));
    return ret;
}

extern inline void pcimem_write_le16(volatile unsigned short *addr, int val)
{
    __asm__ __volatile__("sthbrx %1,0,%2" : "=m" (*addr) :
                  "r" (val), "r" (addr));
}


extern inline unsigned pcimem_read_le32(volatile unsigned *addr)
{
    unsigned ret;

    __asm__ __volatile__("lwbrx %0,0,%1" : "=r" (ret) :
                 "r" (addr), "m" (*addr));
    return ret;
}


extern inline void pcimem_write_le32(volatile unsigned *addr, int val)
{
    __asm__ __volatile__("stwbrx %1,0,%2" : "=m" (*addr) :
                 "r" (val), "r" (addr));
}

#endif /* _PCI_IO_H_ */

RE: switching linux kernels

[Julia Elbert]

Thanks Dan and Graham.
I am in the process of switching to 2.2.14. But, just for your knowledge, my
bug was fixed by turning off the Copy-Back Data Cache fixed my problem.
Now, back to my move to 2.2.14.
Thank you again,
Julia

		-----Original Message-----
		From:	Julia Elbert [mailto:jelbert@enerdyne.com]
		Sent:	Tuesday, September 26, 2000 9:59 AM
		To:	'Dan Malek'; 'linuxppc-embedded@lists.linuxppc.org'
		Subject:	RE: switching linux kernels


		Hi Dan,
		We don't need caching, can we turn it off?
		Thanks.

				-----Original Message-----
				From:	Dan Malek [mailto:dan@mvista.com]
				Sent:	Tuesday, September 26, 2000 8:55 AM
				To:	Julia Elbert
				Cc:
'linuxppc-embedded@lists.linuxppc.org'
				Subject:	Re: switching linux kernels


				Julia Elbert wrote:

				>                 I am switching to HardHat
2.2.13 from ppc
		2.2.13.

				> .....whatsoever, just the data is
corrupted some how.


				Depending upon the flavor of the day ppc
2.2.13, it could be
		a cache
				configuration difference.  The old 2.2.13
kernels often had
		the data
				cache in the write-through mode to avoid a
variety of bugs
		in both
				hardware and software.

				The HHLinux 2.2.13 (and all later kernels)
run with
		copy-back data
				cache and subsequent silicon errata fixes,
so there may be a
		cache
				coherency hole in the way your driver
manages it's space.


					-- Dan

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

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

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

RE: switching linux kernels

[Julia Elbert]

Hi Dan,
We don't need caching, can we turn it off?
Thanks.

		-----Original Message-----
		From:	Dan Malek [mailto:dan@mvista.com]
		Sent:	Tuesday, September 26, 2000 8:55 AM
		To:	Julia Elbert
		Cc:	'linuxppc-embedded@lists.linuxppc.org'
		Subject:	Re: switching linux kernels


		Julia Elbert wrote:

		>                 I am switching to HardHat 2.2.13 from ppc
2.2.13.

		> .....whatsoever, just the data is corrupted some how.


		Depending upon the flavor of the day ppc 2.2.13, it could be
a cache
		configuration difference.  The old 2.2.13 kernels often had
the data
		cache in the write-through mode to avoid a variety of bugs
in both
		hardware and software.

		The HHLinux 2.2.13 (and all later kernels) run with
copy-back data
		cache and subsequent silicon errata fixes, so there may be a
cache
		coherency hole in the way your driver manages it's space.


			-- Dan

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

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

switching linux kernels

[Julia Elbert]

		Hi All,

		I am switching to HardHat 2.2.13 from ppc 2.2.13.
		I have had good luck with everything except for one driver
that we have written.
		We have an hdlc driver that works fine with ppc, when I move
it to Hard Hat, all the bits are fine, we are not losing any data
whatsoever, just the data is corrupted some how.

		What could be going on? Uuggh.
		Thank you,
		--Julia

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

Re: switching linux kernels

[Graham Stoney]

Julia Elbert writes:
> 		I am switching to HardHat 2.2.13 from ppc 2.2.13.

No suggestions about your HDLC problem I'm afraid, but I suggest that you
switch to the 2.2.14 kernel from HardHat-1.2 (the latest) instead.  I just
noticed a nasty bug in fs/dcache.c:dcache_init in 2.2.13, which wastes 2Mb of
RAM on the dentry cache.  Not good in an embedded system, and it's fixed in
2.2.14.

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/

Re: switching linux kernels

[Dan Malek]

Julia Elbert wrote:

>                 I am switching to HardHat 2.2.13 from ppc 2.2.13.

> .....whatsoever, just the data is corrupted some how.


Depending upon the flavor of the day ppc 2.2.13, it could be a cache
configuration difference.  The old 2.2.13 kernels often had the data
cache in the write-through mode to avoid a variety of bugs in both
hardware and software.

The HHLinux 2.2.13 (and all later kernels) run with copy-back data
cache and subsequent silicon errata fixes, so there may be a cache
coherency hole in the way your driver manages it's space.


	-- Dan

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