RE: [PATCH] a new UniCore32 arch-dependent patch for linux-2.6.37-rc1

["Guan Xuetao" <guanxuetao@mprc.pku.edu.cn>]

> -----Original Message-----
> From: linux-arch-owner@vger.kernel.org [mailto:linux-arch-
> owner@vger.kernel.org] On Behalf Of Arnd Bergmann
> Sent: Tuesday, November 30, 2010 12:35 AM
> To: Guan Xuetao
> Cc: 'Greg KH'; 'Andrew Morton'; 'Linus Torvalds'; linux-
> kernel@vger.kernel.org; linux-arch@vger.kernel.org
> Subject: Re: [PATCH] a new UniCore32 arch-dependent patch for linux-
> 2.6.37-rc1
> 
> On Saturday 27 November 2010, Guan Xuetao wrote:
> 
> > > > [Guan] when I set MAX_DMA_ADDRESS to PAGE_OFFSET, some pci
> drivers
> > > > have problem.
> > > >   I will check it later.
> > >
> > > Interesting. You already allow to override MAX_DMA_ADDRESS to
> > > (PAGE_OFFSET + SZ_128M) when PCI is enabled. It would be good to
> > > find out (and document!) the signficance of the extra 128MB here.
> > >
> > PCI controller in PKUnity-3 masks highest 5-bit for upstream channel,
> > so we must Limit the DMA allocation with 128M physical memory for
> > supporting PCI devices.
> >
> > > If it turns out to be required, please make a patch to the
> > > asm-generic/dma.h file to allow overriding MAX_DMA_ADDRESS in the
> > > same way you do in your version.
> > I need to check it later.
> > I suppose MAX_DMA_ADDRESS is virtual address, so it should be larger
> > than PAGE_OFFSET.
> 
> I had a closer look again at this. MAX_DMA_ADDRESS is meant to reflect the
> size of ZONE_DMA, which it does in your patch.
> 
> However, something else is really wrong, in that ZONE_DMA (i.e. GFP_DMA)
> should only be used for legacy ISA devices like floppy or parallel port,
not for
> PCI devices.
> 
> If your PCI bus can only do DMA to a limited memory range, you can not in
> general use MAX_DMA_ADDRESS/ZONE_DMA for this, but instead need to
> use the swiotlb code or a hardware IOMMU in place of your asm/dma-
> mapping.h file.

Ok. Since we have no pci peripherals in our products, I removed these codes.

> 
> > > > > > + * Nothing too fancy for now.
> > > > > > + *
> > > > > > + * On UniCore we already have well known fixed virtual
> > > > > > + addresses imposed by
> > > > > > + * the architecture such as the vector page which is located
> > > > > > + at 0xffff0000,
> > > > >
> > > > > The comment is copied from ARM, but is it really true on unicore?
> > > > >
> > > > [Guan] Yes.
> > >
> > > In what way does the architecture enforce this? What are the
> > > contents of this page? Can you make it an actual VDSO rather than a
> > > magic page that sits in the user address space?
> > Page table is created for vector page and exceptions entry stub.
> > However, vector page is not in the user address space.
> 
> Interesting. So if it's not mapped into user space, why do you even need
to
> have the vectors at a specific page? I think ARM only maps it to the high
page
> because that page is shared to user space, while most architectures just
have
> their interrupt vectors in the linar mapping, since the hardware typically
uses
> the physical address to find it.

In UniCore-32, when MMU enabled, vector page address is virtual address.

> > > You could link against libgcc, see arch/tile/Makefile for an example
> > > how
> > to do
> > > that.
> > Yes, it works. I think it's not a good idea. Kernel should be
> > independent on libgcc.
> 
> I've seen both libgcc based and standalone library approaches in
> architectures, but I could never see a strong reaons for one way or
another.
> Why do you think it should be independent? Licensing technical problems?

No license problem, just my understanding. Thanks.

> 
> > > > > You might not want to select ZONE_DMA and
> > > ARCH_USES_GETTIMEOFFSET,
> > > > > since you are generally better off without them.
> > > > [Guan] We need ZONE_DMA for only 128M low memory could be used
> for
> > > DMA.
> > >
> > > Ok. Is this only for some device drivers, or is this a general
limitation?
> > The ZONE_DMA only limits pci devices, not a general limitation.
> > However, many chips could be connected to different bus, so this limit
> > influences global in our architecture.
> 
> As mentioned above, the drivers behind the PCI (except PCI-ISA bridges)
> should be using dma_map_single/dma_alloc_coherent instead of GFP_DMA
> to get DMA capable memory, so what you need instead is swiotlb.

Ok, thanks.

Guan Xuetao