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.031 / U:31.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site