lkml.org 
[lkml]   [2010]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] a new UniCore32 arch-dependent patch for linux-2.6.37-rc1
Date


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



\
 
 \ /
  Last update: 2010-11-30 11:31    [W:0.131 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site