Re: Latest Altix I/O code reorganization code

[Christoph Hellwig <hch@infradead.org>]

On Tue, Sep 07, 2004 at 05:10:25PM -0500, Patrick Gefre wrote:
>  > of interface beteen upper pci dma code and pcibr code ignored)
>  >
> 
> Guess I'm confused about this then. Are you suggesting putting the pcibr_dma files
> into the pci_dma.c code and not having a pcibr_dma interface ?? The api is there because
> pcibr is an ASIC and is ASIC specific.

No, absolutely not.  I suggested you remove the remaining ASIC-specific
bits from pci_dma.c, namely the decision when to use direct translation
and where to use ates, and the flags and only have a single mapping
routine calling into pcibr code with a prototype ala:

dma_addr_t picbr_dma_map(struct pci_dev *dev, unsigned long phys, size_t size);

>  > > pci_extension.c:
>  > >
>  > >  - dito.  Why does this single function need a separate file?
>  >
>  > Not addressed.  In general your file organization is mess still.
>  >
> 
> How is this:
> arch/ia64/sn/pci/
>                   pci_dma.c
>                   pci_extension.c
>                   pcibr/
>                       pcibr_ate.c
>                       pcibr_dma.c
>                       pcibr_provider.c
>                       pcibr_reg.c
> 
> arch/ia64/sn/kernel/
>                   bte_error.c
>                   io_init.c
>                   iomv.c
> 
> Since pcibr is an ASIC it makes sense for it to have its own directory. There are
> other ASIC interfaces that will be put in in the not too distant future and they
> will go in separate directories also.

Isn't the pcibr_ prefix enough?  This isn't something that would hold up
merging, but I think the additional level is a little silly.

> I will inline free_ate_resource(), alloc_ate_resource() and ate_write(). I want to
> keep the ate code in a separate file - since it is a group of functions with a similar
> theme and is non-trivial.

Okay..

>  > >    of struct tiocp and pic_s (and kill the _s postifx) in syruct pcibus_info.
>  > >    the volatiles looks bogus, if you need it you're missing memorry barries.
>  >
>  > the type pointer isn't done.  Any specific reason?
>  >
> 
> I'm confused on this too. The struct defs are for different MMR sets - so we do need
> to use different types of pointers.

What about adding an union of both _typed_ pointers so you don't need
to cast everytime?


Anyway, it looks like we're making nice progress, thanks for the work.