Re: 64bit build of tulip driver

[Grant Grundler]

On Fri, Apr 01, 2005 at 08:46:33AM -0800, Jim Gifford wrote:
> >Code paths exist in tulip_select_media() where the last thing the
> >driver does to the NIC is io_write(). This could easily be a posted
> >write flush problem. Does replacing flush_cache_all() with 
> >"ioread32(ioaddr + CSR12)" also work?
> >
> >The code immediately before this calls tulip_select_media().
> 
> Didn't work,

Can you try replacing flush_cache_all() with the following?
	ioread32(ioaddr + CSR12);
	udelay(500);	/* random delay until someone looks up what is spec'd */

>  I'm going to revert back and try your code and see if it 
> fixes the issue.

Erm...the code in parisc-linux tree won't have the COBALT hacks.
You might try adding selective bits from the parisc-linux tulip.


That fact the flush_cache_all() changes the behavior made me
wonder if IORESOURCE_CACHEABLE is set in the pci resource.
But that doesn't seem to matter for ppc (32 or 64).
Notes on what I learned below.

arch/ppc64/kernel/iomap.c doesn't look at that flag.
arch/ppc/kernel/io.c:pci_ioremap() has the nice comment:
	        if (flags & IORESOURCE_MEM)
                /* Not checking IORESOURCE_CACHEABLE because PPC does
                 * not currently distinguish between ioremap and
                 * ioremap_nocache. 
                 */
                return ioremap(start, len);

ioremap resolves to:
void __iomem *
ioremap64(unsigned long long addr, unsigned long size)
{
        return __ioremap(addr, size, _PAGE_NO_CACHE);
}

I *think* (too many ifdefs) ppc64 does the same in arch/ppc64/mm/init.c.
Cacheing is clear not an issue for accessing MMIO space via pci_iomap().

grant
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/