lkml.org 
[lkml]   [2005]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 64bit build of tulip driver
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.675 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site