sure
> > > > they use the appropriate DMA APIs which will do cache flushing
> when
> > > > needed.
> > > >
> > > > Adam, what driver is causing you that sort of problems ?
> > > >
> > > > Cheers,
> > > > Ben.
> > &
iginally
> > masked
> > > > out on arch/powerpc, but was fixed in later kernels when the cache
>
> > > > coherency issues with non-SMP systems were resolved).
> > >
> > > I have some doubts about the usefulness of doing that for 4xx.
>
> > I have some doubts about the usefulness of doing that for 4xx. AFAIK,
> > the 440 core just ignores M.
> >
> > The problem lies probably elsewhere. Maybe the L2 cache coherency
> isn't
> > enabled or not working ?
> >
> > The L1 cache on 440 is
nores M.
>
> The problem lies probably elsewhere. Maybe the L2 cache coherency isn't
> enabled or not working ?
>
> The L1 cache on 440 is simply not coherent, so drivers have to make sure
> they use the appropriate DMA APIs which will do cache flushing when
> needed.
>
ssues with non-SMP systems were resolved).
>
> The patch I had fixed two problems on 2.6.26 for 'powerpc':
> 1) It stopped the 'M' bit being masked out (head_32.S)
> 2) It set the cache coherency ('M' bit) flag on each page table entry
> (pgtable-ppc32.h)
architecture. Any help would be appreciated.
Regards,
Adam
--
Adam Zilkie
Software Designer,
International Datacasting Corp.
This message and the documents attached hereto are intended only for the
addressee and may contain privileged or confidential information. Any
unauthorized disclosure is
