public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Colin Ngam <cngam@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Pat Gefre <pfg@sgi.com>,
	akpm@osdl.org, davidm@napali.hpl.hp.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Updating our sn code in 2.6
Date: Fri, 26 Dec 2003 13:42:03 -0600	[thread overview]
Message-ID: <3FEC8F0B.A8C30677@sgi.com> (raw)
In-Reply-To: 20031223165506.A8624@infradead.org

Christoph Hellwig wrote:

> On Tue, Dec 23, 2003 at 08:46:11AM -0600, Colin Ngam wrote:
> > You are ofcourse talking about linux/drivers/.. right?
>
> My plans are to move the code to drivers/xtalk/ once it's finished, es.
>
> > IP27 is not a supported architecture under linux/arch/ia64/sn/io/..
> > The IP27 MIPS processor/io hardware(bridge/Xbridge)/BIOS for IP27 are very much
> > different than our SN2 product, supported within the linux/arch/ia64 tree -
> > ia64 processors, IO Chipsets(PIC, TIO(CP,CA)), and System BIOS.
> >
> > Is that not supported under the linux/arch/mips tree?
>
> It's currently supported, but I'm aiming for common code for the common
> parts (pcibr drivers,  xbow driver, hub/shub driver, xtalk discovery,
> some prom interface code).  I've already sent you my merged dma mapping
> code and I have similar code for hub and bridge/xbridge/pic/tiocp level
> pio mapping and xtalk discovery.
>
> There's of course code that will stay in the per-arch directories like
> the lowlevel interrupt code, etc..  Now this isn't something that happens
> from one day to another, but not not putting stones in the way of each
> other would help greatly..

Hi Christoph,

Yes I agree.  However, keep in mind that we are following the ia32/ia64
way of getting platforms initialized, via ACPI etc.  What you see as
drivers code in sn/io will probably not exist anymore.  All initialization
and configuration will be done at the System BIOS level and information
passed down to the Linux Kernel via ACPI.  This will take away much
code in the kernel.

We believe that all that will be left in sn/io directory maybe files dealing with
DMA mappings(IOMMU).  There will not be any PIO mapping code, no
configuration code, no discovery code, no init code etc. etc.  This is more
in line with what we see, with regards to all other ia64 platforms.

This will not take a day either, but we are trying very hard to accomplish this task

as soon as possible.

The direction that you are taking, we believe, is not the right strategy in Linux.

Thanks.

colin



  reply	other threads:[~2003-12-26 20:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-19  2:59 [PATCH] Updating our sn code in 2.6 Pat Gefre
2003-12-19 11:43 ` Christoph Hellwig
2003-12-20  0:35   ` Pat Gefre
2003-12-20  1:24     ` Jesse Barnes
2003-12-20  3:05       ` Jesse Barnes
2003-12-20 12:27         ` Christoph Hellwig
2003-12-23  2:55           ` Pat Gefre
2003-12-23  9:02             ` Christoph Hellwig
2003-12-23 14:46               ` Colin Ngam
2003-12-23 16:55                 ` Christoph Hellwig
2003-12-26 19:42                   ` Colin Ngam [this message]
2003-12-28 14:44                     ` Christoph Hellwig
2003-12-28 16:32                       ` Colin Ngam
2003-12-28 17:22                         ` Christoph Hellwig
2003-12-29  1:10                           ` Colin Ngam
2003-12-29  1:21                           ` Colin Ngam
2003-12-28 14:36             ` Christoph Hellwig
2003-12-29 23:41               ` Jesse Barnes
2003-12-30 21:21               ` Pat Gefre
2003-12-30 21:24                 ` Christoph Hellwig
2004-01-02 19:47                   ` Patrick Gefre
2004-01-02 20:11                     ` Christoph Hellwig
2004-03-29 15:39                     ` Christoph Hellwig
2004-03-29 15:39                   ` Patrick Gefre
  -- strict thread matches above, loose matches on Subject: below --
2003-11-06 23:31 Pat Gefre
2003-11-07 10:25 ` Christoph Hellwig
2003-11-13  0:26   ` Pat Gefre
2003-11-13  2:42     ` Paul Jackson
2003-11-13  6:58     ` Christoph Hellwig
2003-11-13 16:48       ` Jesse Barnes
2003-11-14 12:10         ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FEC8F0B.A8C30677@sgi.com \
    --to=cngam@sgi.com \
    --cc=akpm@osdl.org \
    --cc=davidm@napali.hpl.hp.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pfg@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox