LinuxLists.cc - [PATCH] Updating our sn code in 2.6

2003-11-06 23:33:22

Subject: [PATCH] Updating our sn code in 2.6

2003-11-07 23:45:43

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

On Thu, Nov 06, 2003 at 05:31:56PM -0600, Pat Gefre wrote:
> I have a patch for 2.6 that will update our sn I/O. This patch includes
> initial support for new h/w, some code reorganization to accomodate the
> new h/w, fixes to our code since the last bulk update earlier this year
> and code clean-up. The diffstat follows at the end of this email.

Well, it would be nice again to give credit for people who did this.
In fact that SGI let code slip in that clearly wasn't theirs I think you should
really identidy who changed what instead of a hude 1.4MB patch.

Comments to the patch:
- don't reintroduce pciba, it's a broken driver and I removed it
for a reason. Use the generic pci procfs and sysfs infrastructure.
- please handle OOM situation instead of BUG()ing.
- please don't introduce empty functions just for the sake of it
(e.g. per_ice_init)
- the ioc4 driver is a mess, please rewrite it as a proper linux
driver using serial_core, etc.. instead of glueing an irix driver
through a midlyer directly to the tty interface.
- please don't kill xbridge support from pcibr, we want to reuse
it for the ip27 port soon
- please kill the crap under PCI_HOTPLUG - that wants implementing
as a proper linux hotplug pci driver instead.
- msi support should go into generic code, not sn2-specific. See
the patches in Andrew's tree.
- please use the generic pci-to-pci bridge code instead of reiplenting
it. Guy you drive me nuts with your silly hack it up on irix and
glue it into linux strategy!
- __HAVE_NEW_SCHEDULER is always true for 2.6, but you don't appear
to actually use it..
- the ifdefs in the tio code are broken, you dma mapping has zero
chance to work for generic kernels
- snia_if adds back the snia_pciio interface that were killed for
a reason, don't do that!
- you back out all changes to xswitch.c in 2.6, why?

all in all this patch is a big mess and it looks like you just took the
code from your tree and diffed vs what's in 2.6. Please provide a patch
per thing, properly explained and reviewd.

2003-11-13 00:27:56

by Patrick Gefre

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

I've updated this patch (see comments below) and am posting the url again.

ftp://oss.sgi.com/pub/outgoing

I realize that the tree is currently closed, but think this is at least
an opportunity to get this reviewed and ready when the tree re-opens.

arch/ia64/sn/Makefile | 2
arch/ia64/sn/io/Makefile | 6
arch/ia64/sn/io/cdl.c | 16
arch/ia64/sn/io/drivers/Makefile | 2
arch/ia64/sn/io/drivers/ioconfig_bus.c | 119 -
arch/ia64/sn/io/hwgfs/Makefile | 2
arch/ia64/sn/io/hwgfs/hcl.c | 273 --
arch/ia64/sn/io/hwgfs/hcl_util.c | 68
arch/ia64/sn/io/hwgfs/interface.c | 46
arch/ia64/sn/io/hwgfs/labelcl.c | 1
arch/ia64/sn/io/io.c | 44
arch/ia64/sn/io/machvec/Makefile | 2
arch/ia64/sn/io/machvec/pci.c | 35
arch/ia64/sn/io/machvec/pci_bus_cvlink.c | 805 +++-----
arch/ia64/sn/io/machvec/pci_dma.c | 130 -
arch/ia64/sn/io/platform_init/Makefile | 2
arch/ia64/sn/io/platform_init/irix_io_init.c | 69
arch/ia64/sn/io/sgi_if.c | 136 -
arch/ia64/sn/io/sgi_io_sim.c | 79
arch/ia64/sn/io/sn2/Makefile | 9
arch/ia64/sn/io/sn2/bte_error.c | 67
arch/ia64/sn/io/sn2/geo_op.c | 4
arch/ia64/sn/io/sn2/klconflib.c | 201 +-
arch/ia64/sn/io/sn2/klgraph.c | 487 +----
arch/ia64/sn/io/sn2/l1_command.c | 91
arch/ia64/sn/io/sn2/ml_SN_init.c | 71
arch/ia64/sn/io/sn2/ml_SN_intr.c | 26
arch/ia64/sn/io/sn2/ml_iograph.c | 355 +--
arch/ia64/sn/io/sn2/module.c | 145 -
arch/ia64/sn/io/sn2/pcibr/Makefile | 9
arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c | 440 ----
arch/ia64/sn/io/sn2/pcibr/pcibr_config.c | 223 +-
arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c | 2498 ++++++--------------------
arch/ia64/sn/io/sn2/pcibr/pcibr_error.c | 1349 ++++++++------
arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c | 51
arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c | 525 +----
arch/ia64/sn/io/sn2/pcibr/pcibr_reg.c | 2264 ++++++++++++++++++++++++
arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c | 414 ++--
arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c | 1069 +++--------
arch/ia64/sn/io/sn2/pciio.c | 532 +----
arch/ia64/sn/io/sn2/pic.c | 728 ++++++-
arch/ia64/sn/io/sn2/shub.c | 73
arch/ia64/sn/io/sn2/shub_intr.c | 96 -
arch/ia64/sn/io/sn2/shuberror.c | 24
arch/ia64/sn/io/sn2/shubio.c | 22
arch/ia64/sn/io/sn2/xbow.c | 532 -----
arch/ia64/sn/io/sn2/xtalk.c | 88
arch/ia64/sn/io/snia_if.c | 144 +
arch/ia64/sn/io/xswitch.c | 4
arch/ia64/sn/kernel/Makefile | 2
arch/ia64/sn/kernel/irq.c | 134 -
arch/ia64/sn/kernel/setup.c | 88
arch/ia64/sn/kernel/sn2/Makefile | 4
arch/ia64/sn/kernel/sn2/cache.c | 20
arch/ia64/sn/kernel/sn2/timer_interrupt.c | 76
drivers/char/sn_serial.c | 324 ++-
include/asm-ia64/sn/addrs.h | 33
include/asm-ia64/sn/alenlist.h | 3
include/asm-ia64/sn/arc/hinv.h | 183 -
include/asm-ia64/sn/arc/types.h | 41
include/asm-ia64/sn/arch.h | 3
include/asm-ia64/sn/bte.h | 23
include/asm-ia64/sn/cdl.h | 5
include/asm-ia64/sn/clksupport.h | 3
include/asm-ia64/sn/dmamap.h | 29
include/asm-ia64/sn/driver.h | 3
include/asm-ia64/sn/geo.h | 9
include/asm-ia64/sn/hcl.h | 40
include/asm-ia64/sn/hcl_util.h | 5
include/asm-ia64/sn/hwgfs.h | 6
include/asm-ia64/sn/intr.h | 3
include/asm-ia64/sn/invent.h | 733 -------
include/asm-ia64/sn/io.h | 6
include/asm-ia64/sn/ioc4.h | 801 --------
include/asm-ia64/sn/ioconfig_bus.h | 39
include/asm-ia64/sn/ioerror.h | 7
include/asm-ia64/sn/ioerror_handling.h | 54
include/asm-ia64/sn/iograph.h | 83
include/asm-ia64/sn/klconfig.h | 359 ---
include/asm-ia64/sn/ksys/elsc.h | 9
include/asm-ia64/sn/ksys/l1.h | 37
include/asm-ia64/sn/labelcl.h | 16
include/asm-ia64/sn/module.h | 15
include/asm-ia64/sn/nag.h | 32
include/asm-ia64/sn/nodepda.h | 3
include/asm-ia64/sn/pci/bridge.h | 1901 --------------------
include/asm-ia64/sn/pci/pci_bus_cvlink.h | 18
include/asm-ia64/sn/pci/pci_defs.h | 267 +-
include/asm-ia64/sn/pci/pcibr.h | 84
include/asm-ia64/sn/pci/pcibr_asic.h | 511 +++++
include/asm-ia64/sn/pci/pcibr_private.h | 328 ++-
include/asm-ia64/sn/pci/pciio.h | 156 +
include/asm-ia64/sn/pci/pciio_private.h | 89
include/asm-ia64/sn/pci/pic.h | 2521 ++++++---------------------
include/asm-ia64/sn/pda.h | 4
include/asm-ia64/sn/pio.h | 7
include/asm-ia64/sn/prio.h | 3
include/asm-ia64/sn/router.h | 3
include/asm-ia64/sn/sgi.h | 134 -
include/asm-ia64/sn/simulator.h | 2
include/asm-ia64/sn/slotnum.h | 3
include/asm-ia64/sn/sn2/addrs.h | 40
include/asm-ia64/sn/sn2/arch.h | 5
include/asm-ia64/sn/sn2/geo.h | 9
include/asm-ia64/sn/sn2/intr.h | 7
include/asm-ia64/sn/sn2/shub.h | 1
include/asm-ia64/sn/sn2/shub_md.h | 7
include/asm-ia64/sn/sn2/shubio.h | 8
include/asm-ia64/sn/sn2/sn_private.h | 11
include/asm-ia64/sn/sn_fru.h | 3
include/asm-ia64/sn/sn_private.h | 3
include/asm-ia64/sn/sn_sal.h | 43
include/asm-ia64/sn/vector.h | 3
include/asm-ia64/sn/xtalk/xbow.h | 227 --
include/asm-ia64/sn/xtalk/xbow_info.h | 55
include/asm-ia64/sn/xtalk/xswitch.h | 9
include/asm-ia64/sn/xtalk/xtalk.h | 20
include/asm-ia64/sn/xtalk/xtalk_private.h | 15
include/asm-ia64/sn/xtalk/xtalkaddrs.h | 9
include/asm-ia64/sn/xtalk/xwidget.h | 84
120 files changed, 9147 insertions(+), 15052 deletions(-)

On Fri, 7 Nov 2003, Christoph Hellwig wrote:

+ On Thu, Nov 06, 2003 at 05:31:56PM -0600, Pat Gefre wrote:
+ > I have a patch for 2.6 that will update our sn I/O. This patch includes
+ > initial support for new h/w, some code reorganization to accomodate the
+ > new h/w, fixes to our code since the last bulk update earlier this year
+ > and code clean-up. The diffstat follows at the end of this email.
+
+ Well, it would be nice again to give credit for people who did this.
+ In fact that SGI let code slip in that clearly wasn't theirs I think you should
+ really identidy who changed what instead of a hude 1.4MB patch.

I'm not sure what you mean here. Was there something specific ? One of
the reasons this is so large is because we hadn't sent any updates in
months, so we are in a bit of a catch-up mode. In the months since our
last updates, we have had several rounds of code clean up, fixed a
number of bugs and re-organized our code - something we feel we will
need down the road.

+
+ Comments to the patch:
+ - don't reintroduce pciba, it's a broken driver and I removed it
+ for a reason. Use the generic pci procfs and sysfs infrastructure.

OK.

+ - please handle OOM situation instead of BUG()ing.

OK.

+ - please don't introduce empty functions just for the sake of it
+ (e.g. per_ice_init)

OK.

+ - the ioc4 driver is a mess, please rewrite it as a proper linux
+ driver using serial_core, etc.. instead of glueing an irix driver
+ through a midlyer directly to the tty interface.

I took this out. Is the only complaint that I didn't use the serial
core interface ?

+ - please don't kill xbridge support from pcibr, we want to reuse
+ it for the ip27 port soon

Not sure what you mean here. I'm pretty sure if this code is needed for
a non-ia64 system it won't be in the sn2 code.

+ - please kill the crap under PCI_HOTPLUG - that wants implementing
+ as a proper linux hotplug pci driver instead.

OK.

+ - msi support should go into generic code, not sn2-specific. See
+ the patches in Andrew's tree.

OK.

+ - please use the generic pci-to-pci bridge code instead of reiplenting
+ it.

OK.

+ - __HAVE_NEW_SCHEDULER is always true for 2.6, but you don't appear
+ to actually use it..

What did you mean here ?

+ - the ifdefs in the tio code are broken, you dma mapping has zero
+ chance to work for generic kernels

OK.

+ - snia_if adds back the snia_pciio interface that were killed for
+ a reason, don't do that!

OK. I did however move the ones that we were using into this file.

+ - you back out all changes to xswitch.c in 2.6, why?
+

OK.

2003-11-13 02:44:04

by Paul Jackson

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

This patch still seems way too monolithic, Pat.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373

2003-11-13 06:58:49

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

> + In fact that SGI let code slip in that clearly wasn't theirs I think you should
> + really identidy who changed what instead of a hude 1.4MB patch.
>
> I'm not sure what you mean here. Was there something specific ?

ate_malloc & co..

> One of
> the reasons this is so large is because we hadn't sent any updates in
> months, so we are in a bit of a catch-up mode. In the months since our
> last updates, we have had several rounds of code clean up, fixed a
> number of bugs and re-organized our code - something we feel we will
> need down the road.

It needs to be split into piecees anyway. The patch is a big mess and by
splitting it into smaller parts you can describe what each patch does,
maybe notice the problems with it yourself or at least give us a better
opportunity to review it properly. Really, it is a lot of work but it will
pay off.

> + - the ioc4 driver is a mess, please rewrite it as a proper linux
> + driver using serial_core, etc.. instead of glueing an irix driver
> + through a midlyer directly to the tty interface.
>
> I took this out. Is the only complaint that I didn't use the serial
> core interface ?

No. The complaint is that the driver is an utteer mess. It's basically
a badly written IRIX driver glued into a copy of the Linux serial driver
that doesn't even compile on 2.6. Get real, and take a look at it..

> + - please don't kill xbridge support from pcibr, we want to reuse
> + it for the ip27 port soon
>
> Not sure what you mean here. I'm pretty sure if this code is needed for
> a non-ia64 system it won't be in the sn2 code.

Well, given that the ip27 is basically the same system architecture as
sn2 we want to resuse that code. Whether it stays in arch/ia64/ or goes
to drivers/xtalk is a different question. Also note that you can just
make the IS_PIC calls evulate to 1 always in your build, any recent gcc
will optimize away the xbridge codepathes then

>
> + - __HAVE_NEW_SCHEDULER is always true for 2.6, but you don't appear
> + to actually use it..
>
> What did you mean here ?

grep for __HAVE_NEW_SCHEDULER over your tree :)

2003-11-13 16:48:51

by Jesse Barnes

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

On Thu, Nov 13, 2003 at 06:58:44AM +0000, Christoph Hellwig wrote:
> > + - please don't kill xbridge support from pcibr, we want to reuse
> > + it for the ip27 port soon
> >
> > Not sure what you mean here. I'm pretty sure if this code is needed for
> > a non-ia64 system it won't be in the sn2 code.
>
> Well, given that the ip27 is basically the same system architecture as
> sn2 we want to resuse that code. Whether it stays in arch/ia64/ or goes
> to drivers/xtalk is a different question. Also note that you can just
> make the IS_PIC calls evulate to 1 always in your build, any recent gcc
> will optimize away the xbridge codepathes then

Are you sure you want to handle it this way? I'm not sure the code is
very useful in its current state--I think we might be better off
downloading an old kernel version for reference and writing new code for
drivers/xtalk.

Then again, starting with the existing mips code might be even better
since we know that worked at one point.

Jesse

2003-11-14 12:10:07

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

On Thu, Nov 13, 2003 at 08:48:01AM -0800, Jesse Barnes wrote:
> Are you sure you want to handle it this way? I'm not sure the code is
> very useful in its current state--I think we might be better off
> downloading an old kernel version for reference and writing new code for
> drivers/xtalk.

Well, maybe that would be a better idea. But if you remove the xbridge
support please do it as a separate diff so it can be archive easily.

2004-01-02 19:56:09

by Patrick Gefre

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

Christoph Hellwig wrote:

>On Tue, Dec 30, 2003 at 03:21:13PM -0600, Pat Gefre wrote:
>
>
>>I'll drop 071. So I can assume that if I get rid of the renaming in 075
>>you are OK with that ?
>>
>>
>
>Yes. I don't like some of the stuff it doesn, but it's defintily not
>a showstopper.
>
>
OK - I updated the patches as Christoph suggested (removed
hwgraph_path_lookup() from 000, removed
snia64_pci_find_bios() from 014, removed pcibr_businfo_get() from 030
and dropped 071).

I took the reorg patch (075) out for now - I am reworking it along with
our next set of patches.

So I think they are ready to go ?

The patchset is at: ftp://oss.sgi.com/projects/sn2/sn2-update/

-- Pat

2004-01-02 20:12:23

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

On Fri, Jan 02, 2004 at 01:47:42PM -0600, Patrick Gefre wrote:
> OK - I updated the patches as Christoph suggested (removed
> hwgraph_path_lookup() from 000, removed
> snia64_pci_find_bios() from 014, removed pcibr_businfo_get() from 030
> and dropped 071).
>
> I took the reorg patch (075) out for now - I am reworking it along with
> our next set of patches.
>
> So I think they are ready to go ?

Yes. 030 still has some really strange additions but we can back that
out later.

For the next round of patched I would be nice if you could get the
attribution of the patches right, though..

2004-01-10 21:39:53

by Colin Ngam

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

Christoph Hellwig wrote:

> On Sun, Dec 28, 2003 at 10:32:51AM -0600, Colin Ngam wrote:
> > > the now almost legacy SHUB/PIC based Altixens? Well, even if SGI does this
> >
> > SHUB/PIC based Altixens are not Legacy in any form shape or manner. I expect
> > these IO Chipsets to drive Altix for the foreseable near future ..
>
> Well, it looks like TIO is replacing it soon, doesn't it?
>
> > Please do not question my resolve to drive us towards this direction. Things can
> > always change, but I am heading this direction.
>
> Well, again talk is cheap, if you show the code this whole discussion
> would be avoid. I've done my part of showing the code and the only thing
> I get in reply is bad flames and random obsfucations to break that code.

Hi Christoph,

I do not believe I have sent any "bad flames" or any flames, at all to you
regarding this issue. That would just be rude and bad culture. It is just not
that way I conduct business as we all have so much to contribute.

I am just trying to share with you our plans. That's only fair to you.

Thanks.

colin

>
>
> > architecture. That is not a problem at all. For ia64 Altix line, we want
> > to follow what's being done on other ia64 platform. Is this not the
> > right approach? You yourself had mentioned above that this is the
> > way to go?
>
> Again, I'd be more than happy if you moved that code to the PROM. But as
> long as we have code in the kernel to deal with that hardware different ports
> should share it. And as mentioned above I have that strong feeling that
> for the first generation Altixens this is never going to happen. Of course
> I'd be more than happy to be proven wrong.
>
> > This code sharing will not be possible when we do all of our initialization
> > in System BIOS, just like every other ia64 platform.
>
> Again, if you do that I'd be more than happy. But as long as we need that
> code in the kernel it should be done properly.
>
> > Moreover, the ia64
> > Altix line does not support Bridge/Xbridge chipsets and we do not want
> > to be burdened by these legacy code as we move forward with the ia64
> > product line.
>
> Guess what, the current iommu code has exactly three lines of code that
> make sense only for bridge. Not to mention that I'll have no problem with
> maintaining all that code, so you don't have to maintain more but rather
> less code. (In a double sense, given that the new code is also much
> smaller despite support for the older revisions)

2004-03-29 15:39:11

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] Updating our sn code in 2.6

2004-03-29 15:39:01

by Patrick Gefre

[permalink] [raw]