[PATCH] Updating our sn code in 2.6

[PATCH] Updating our sn code in 2.6

[Pat Gefre]

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.

The patch can be viewed from :
ftp://oss.sgi.com/pub/outgoing

Thanks,
-- Pat

Patrick Gefre
Silicon Graphics, Inc.                     (E-Mail)  pfg@sgi.com
2750 Blue Water Rd                         (Voice)   (651) 683-3127
Eagan, MN 55121-1400                       (FAX)     (651) 683-3054


 arch/ia64/sn/Makefile                        |    2
 arch/ia64/sn/fakeprom/fpmem.c                |  222 +-
 arch/ia64/sn/fakeprom/fpmem.h                |   31
 arch/ia64/sn/fakeprom/fpromasm.S             |   12
 arch/ia64/sn/fakeprom/fw-emu.c               |  168 -
 arch/ia64/sn/fakeprom/klgraph_fake.c         |  373 +++
 arch/ia64/sn/fakeprom/klgraph_init.c         |    4
 arch/ia64/sn/fakeprom/main.c                 |  101 -
 arch/ia64/sn/io/Makefile                     |    6
 arch/ia64/sn/io/cdl.c                        |   23
 arch/ia64/sn/io/drivers/Makefile             |    2
 arch/ia64/sn/io/drivers/ioconfig_bus.c       |   87
 arch/ia64/sn/io/drivers/pciba.c              |  917 +++++++++
 arch/ia64/sn/io/hwgfs/Makefile               |    2
 arch/ia64/sn/io/hwgfs/hcl.c                  |  249 --
 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     |  445 ++--
 arch/ia64/sn/io/machvec/pci_dma.c            |   45
 arch/ia64/sn/io/platform_init/Makefile       |    2
 arch/ia64/sn/io/platform_init/irix_io_init.c |   76
 arch/ia64/sn/io/platform_init/sgi_io_init.c  |   15
 arch/ia64/sn/io/sgi_if.c                     |   34
 arch/ia64/sn/io/sgi_io_sim.c                 |   79
 arch/ia64/sn/io/sn2/Makefile                 |    9
 arch/ia64/sn/io/sn2/bte_error.c              |   36
 arch/ia64/sn/io/sn2/geo_op.c                 |    4
 arch/ia64/sn/io/sn2/ioc4/Makefile            |   21
 arch/ia64/sn/io/sn2/ioc4/ioc4.c              |  649 ++++++
 arch/ia64/sn/io/sn2/ioc4/sio_ioc4.c          | 2289 +++++++++++++++++++++++
 arch/ia64/sn/io/sn2/klconflib.c              |  160 -
 arch/ia64/sn/io/sn2/klgraph.c                |  444 ++--
 arch/ia64/sn/io/sn2/l1_command.c             |   44
 arch/ia64/sn/io/sn2/ml_SN_init.c             |   71
 arch/ia64/sn/io/sn2/ml_SN_intr.c             |   52
 arch/ia64/sn/io/sn2/ml_iograph.c             |  427 ++--
 arch/ia64/sn/io/sn2/module.c                 |  141 -
 arch/ia64/sn/io/sn2/pcibr/Makefile           |    9
 arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c        |  415 ----
 arch/ia64/sn/io/sn2/pcibr/pcibr_config.c     |  223 +-
 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c        | 2505 ++++++--------------------
 arch/ia64/sn/io/sn2/pcibr/pcibr_error.c      | 1299 +++++++------
 arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c      |   38
 arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c       |  425 +---
 arch/ia64/sn/io/sn2/pcibr/pcibr_msix_intr.c  |  264 ++
 arch/ia64/sn/io/sn2/pcibr/pcibr_reg.c        | 2592 +++++++++++++++++++++++++++
 arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c        |  406 ++--
 arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c       | 1009 +++++++---
 arch/ia64/sn/io/sn2/pciio.c                  |  530 +----
 arch/ia64/sn/io/sn2/pciio_ppb.c              | 1550 ++++++++++++++++
 arch/ia64/sn/io/sn2/pic.c                    |  691 ++++++-
 arch/ia64/sn/io/sn2/shub.c                   |   78
 arch/ia64/sn/io/sn2/shub_intr.c              |   96 -
 arch/ia64/sn/io/sn2/shuberror.c              |   14
 arch/ia64/sn/io/sn2/shubio.c                 |   14
 arch/ia64/sn/io/sn2/tio.c                    |  743 +++++++
 arch/ia64/sn/io/sn2/tio_intr.c               |  166 +
 arch/ia64/sn/io/sn2/tiocp.c                  |  963 ++++++++++
 arch/ia64/sn/io/sn2/xbow.c                   |  529 -----
 arch/ia64/sn/io/sn2/xtalk.c                  |   96 -
 arch/ia64/sn/io/snia_if.c                    |  278 ++
 arch/ia64/sn/io/tio/Makefile                 |   10
 arch/ia64/sn/io/tio/ca/Makefile              |   10
 arch/ia64/sn/io/tio/ca/ca_driver.c           |   75
 arch/ia64/sn/io/tio/ca/ca_error.c            |  147 +
 arch/ia64/sn/io/tio/ca/ca_linux.c            |  246 ++
 arch/ia64/sn/io/tio/ca/ca_pci.c              | 1281 +++++++++++++
 arch/ia64/sn/io/xswitch.c                    |   72
 arch/ia64/sn/kernel/Makefile                 |    2
 arch/ia64/sn/kernel/irq.c                    |  137 -
 arch/ia64/sn/kernel/setup.c                  |   86
 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/ioc4_serial.c                   | 1840 +++++++++++++++++++
 drivers/char/sn_serial.c                     |    3
 include/asm-ia64/sn/addrs.h                  |   42
 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/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               |    3
 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                     |    3
 include/asm-ia64/sn/ioc4.h                   |   80
 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                |   85
 include/asm-ia64/sn/klconfig.h               |  277 --
 include/asm-ia64/sn/ksys/elsc.h              |    9
 include/asm-ia64/sn/ksys/l1.h                |   38
 include/asm-ia64/sn/labelcl.h                |   16
 include/asm-ia64/sn/module.h                 |   16
 include/asm-ia64/sn/nag.h                    |   32
 include/asm-ia64/sn/nodepda.h                |    5
 include/asm-ia64/sn/pci/bridge.h             | 1901 -------------------
 include/asm-ia64/sn/pci/pci_bus_cvlink.h     |   12
 include/asm-ia64/sn/pci/pci_defs.h           |  203 +-
 include/asm-ia64/sn/pci/pciba.h              |  113 +
 include/asm-ia64/sn/pci/pcibr.h              |   85
 include/asm-ia64/sn/pci/pcibr_asic.h         |  511 +++++
 include/asm-ia64/sn/pci/pcibr_private.h      |  314 ++-
 include/asm-ia64/sn/pci/pciio.h              |  167 +
 include/asm-ia64/sn/pci/pciio_private.h      |   89
 include/asm-ia64/sn/pci/pic.h                | 2499 +++++---------------------
 include/asm-ia64/sn/pci/tiocp.h              |  588 ++++++
 include/asm-ia64/sn/pda.h                    |    4
 include/asm-ia64/sn/pio.h                    |    3
 include/asm-ia64/sn/prio.h                   |    3
 include/asm-ia64/sn/router.h                 |    3
 include/asm-ia64/sn/serialio.h               |  462 ++++
 include/asm-ia64/sn/sgi.h                    |  150 -
 include/asm-ia64/sn/simulator.h              |    2
 include/asm-ia64/sn/slotnum.h                |    3
 include/asm-ia64/sn/sn2/addrs.h              |   58
 include/asm-ia64/sn/sn2/arch.h               |    5
 include/asm-ia64/sn/sn2/geo.h                |    9
 include/asm-ia64/sn/sn2/iceio.h              |  162 +
 include/asm-ia64/sn/sn2/intr.h               |    8
 include/asm-ia64/sn/sn2/shub.h               |    1
 include/asm-ia64/sn/sn2/shub_md.h            |    7
 include/asm-ia64/sn/sn2/shub_mmr_t.h         |    1
 include/asm-ia64/sn/sn2/shubio.h             |    8
 include/asm-ia64/sn/sn2/sn_private.h         |    9
 include/asm-ia64/sn/sn2/tio.h                |   45
 include/asm-ia64/sn/sn_fru.h                 |    3
 include/asm-ia64/sn/sn_private.h             |    3
 include/asm-ia64/sn/tio/tioca.h              |  482 +++++
 include/asm-ia64/sn/tio/tioca_private.h      |   61
 include/asm-ia64/sn/tio/tioca_soft.h         |   80
 include/asm-ia64/sn/vector.h                 |    3
 include/asm-ia64/sn/xtalk/corelet.h          |   22
 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            |   28
 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
 152 files changed, 23736 insertions(+), 12917 deletions(-)

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

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.

Re: [PATCH] Updating our sn code in 2.6

[Pat Gefre]

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.

Re: [PATCH] Updating our sn code in 2.6

[Paul Jackson]

This patch still seems way too monolithic, Pat.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

> + 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 :)

Re: [PATCH] Updating our sn code in 2.6

[Jesse Barnes]

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

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

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.

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

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

Re: [PATCH] Updating our sn code in 2.6

[Patrick Gefre]

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

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

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

Re: [PATCH] Updating our sn code in 2.6

[Patrick Gefre]

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

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

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.

Re: [PATCH] Updating our sn code in 2.6

[Pat Gefre]

On Sun, 28 Dec 2003, Christoph Hellwig wrote:

+ On Mon, Dec 22, 2003 at 08:55:10PM -0600, Pat Gefre wrote:
+ > + issues before merging, it's not that much anyway..
+ > 
+ > I think I did. I sent another email with the changes I made for the
+ > issues you raised - and updated the patches. If I missed any, please
+ > let me know.
+ 
+ Looking at oss.sgi.com/projects/sn2/sn2-update:
+ 
+  - no change in 000-hwgfs-update.patch.inprogress, hwgraph_path_lookup
+    shall not be reintroduced.
+  - 014-cleanup-pci.c.patch:  no change apparently?
+  - 030-pciio-cleanup.patch: Dito
+  - 071-xswitch.devfunc.patch: Dito.
+  - 075-rename-reorg.patch: Dito
+ 
+ 
+ > David or Andrew can you take these patches ?
+ 
+ Really, that's not what I consider fixing.  Please fix up
+ 000,014 and 030 and drop 071 and 075, then it should be fine for
+ merging.  071 shouldn't go in at all and 075 needs the renaming killed,
+ everything else can go in although it's not nice.
+ 

I've been out of town, so haven't responded to this yet.

I'll remove hwgraph_path_lookup() from 000, remove snia64_pci_find_bios()
from 014 and remove pcibr_businfo_get() from 030.

I'll drop 071. So I can assume that if I get rid of the renaming in 075
you are OK with that ?

Re: [PATCH] Updating our sn code in 2.6

[Jesse Barnes]

On Sun, Dec 28, 2003 at 02:36:03PM +0000, Christoph Hellwig wrote:
>  - no change in 000-hwgfs-update.patch.inprogress, hwgraph_path_lookup
>    shall not be reintroduced.

Pat, it looks like hwgraph_path_lookup() is only used in the PCI hotplug
code, and is messed up anyway (it's looking for a SCSI controller??), so
we can probably kill the addition of that function.

>  - 014-cleanup-pci.c.patch:  no change apparently?

Yeah, it would be nice to avoid introducing stuff that just gets deleted
in later patches.

>  - 030-pciio-cleanup.patch: Dito

Not sure what this is about...

>  - 071-xswitch.devfunc.patch: Dito.

Yes, I think we do have more xswitches coming...

>  - 075-rename-reorg.patch: Dito

If this stuff is going to be used by more than just ia64, it should
probably be moved to another directory/file.

> > David or Andrew can you take these patches ?
> 
> Really, that's not what I consider fixing.  Please fix up
> 000,014 and 030 and drop 071 and 075, then it should be fine for
> merging.  071 shouldn't go in at all and 075 needs the renaming killed,
> everything else can go in although it's not nice.

Pat, will the patches work if we omit 071 and 075?  If so, maybe we can
get the others merged in and continue to work on the last two.

Jesse

Re: [PATCH] Updating our sn code in 2.6

[Colin Ngam]

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)

Re: [PATCH] Updating our sn code in 2.6

[Colin Ngam]

Christoph Hellwig wrote:

Hi Christoph,

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

I am not privy to that kind of information.  SGI has always
maintained and supported systems with more than 1 IO Chipset on
the same system.  So, we will have SHUB/PIC and TIO IO
Chipset on the same system once TIO goes into production.


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

All I am saying is that we have an effort going towards that direction.  I
am trying to work with you, letting you know ahead of time what is coming
down so that future effort you are expanding is not wasted.

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

I am not out to prove you right or wrong - that is irrelevent.  We are not moving
code to Prom, we are enhancing our current functionality in Prom so that
we will not need these code in the Linux kernel anymore.  Prom already
has most of these functionalities.

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

I will have a problem, if SGI is not the maintainer of our IO Chipset code for
ia64/Altix.  When this is done, there will be very little kernel code left
to be maintained anyway.  It will make life much better for us all, as we can
concentrate on other parts of the kernel.

I believe we have beaten this topic to death now.  You know what we are trying
to accomplish - that is to follow as closely as possible the current methodology
ia32/ia64 platforms are using for platform initialization - in System BIOS and
ACPI.  This will enable us to yank a tremendous amount of code from the
kernel, making sn2 only and also Generic ia64 kernel much smaller, and the
sn2 platform specific code much easier to maintain and understand.

It would have been very rude of us, not to inform you of our plans, given the fact
that you have shared your intention.  That would just waste your time.

Thanks.

colin

>

>

>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

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.

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

Re: [PATCH] Updating our sn code in 2.6

[Colin Ngam]

Christoph Hellwig wrote:

Hi Christoph,

> On Fri, Dec 26, 2003 at 01:42:03PM -0600, Colin Ngam wrote:
> > 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.
>
> Well, I've heard this a few times now and life would definitly be simpler

>
> if you're going down that route.  OTOH we all know talk is cheap and code
> speaks, and do you really expect SGI to invest money into doing that for
> 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 ..

Please do not question my resolve to drive us towards this direction.  Things can
always change, but I am heading this direction.

>
> some day it won't really hurt us to get the code in shape first even if
> it's only use on MIPS IP27/IP35, wouldn't it?

Please, you can do what you want with the maintainer for the MIPs
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?

>
>
> > We believe that all that will be left in sn/io directory maybe files dealing with
> > DMA mappings(IOMMU).
>
> That's one of the candidates that really should be shared with IP27 and the
> once someone does them the IP30 and IP35 ports.  Really, the basic dma mapping
> code is the same for Bridge/Xbridge/PIC/TIOCP so we should have one driver.
> And once all the IRIX I/O infrastructure depency is ripped out that part of
> pcibr is rather self-contained.  I can send you my latest variant of the
> dma mapping code if you want, but due tue all that stupid renaming of
> structure and macro names it won't compile in your tree.  See why I _really_
> _really_ dislike that silly renaming?  It breaks all those nice efforts
> for code-sharing without any gain.

This code sharing will not be possible when we do all of our initialization
in System BIOS, just like every other ia64 platform.  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.

Thanks.

colin

>
>
> Even IRIX TOT uses the 'old' names, so what is the point of renaming them?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

On Fri, Dec 26, 2003 at 01:42:03PM -0600, Colin Ngam wrote:
> 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.

Well, I've heard this a few times now and life would definitly be simpler
if you're going down that route.  OTOH we all know talk is cheap and code
speaks, and do you really expect SGI to invest money into doing that for
the now almost legacy SHUB/PIC based Altixens?  Well, even if SGI does this
some day it won't really hurt us to get the code in shape first even if
it's only use on MIPS IP27/IP35, wouldn't it?

> We believe that all that will be left in sn/io directory maybe files dealing with
> DMA mappings(IOMMU).

That's one of the candidates that really should be shared with IP27 and the
once someone does them the IP30 and IP35 ports.  Really, the basic dma mapping
code is the same for Bridge/Xbridge/PIC/TIOCP so we should have one driver.
And once all the IRIX I/O infrastructure depency is ripped out that part of
pcibr is rather self-contained.  I can send you my latest variant of the
dma mapping code if you want, but due tue all that stupid renaming of
structure and macro names it won't compile in your tree.  See why I _really_
_really_ dislike that silly renaming?  It breaks all those nice efforts
for code-sharing without any gain.

Even IRIX TOT uses the 'old' names, so what is the point of renaming them?

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

On Mon, Dec 22, 2003 at 08:55:10PM -0600, Pat Gefre wrote:
> + issues before merging, it's not that much anyway..
> 
> I think I did. I sent another email with the changes I made for the
> issues you raised - and updated the patches. If I missed any, please
> let me know.

Looking at oss.sgi.com/projects/sn2/sn2-update:

 - no change in 000-hwgfs-update.patch.inprogress, hwgraph_path_lookup
   shall not be reintroduced.
 - 014-cleanup-pci.c.patch:  no change apparently?
 - 030-pciio-cleanup.patch: Dito
 - 071-xswitch.devfunc.patch: Dito.
 - 075-rename-reorg.patch: Dito


> David or Andrew can you take these patches ?

Really, that's not what I consider fixing.  Please fix up
000,014 and 030 and drop 071 and 075, then it should be fine for
merging.  071 shouldn't go in at all and 075 needs the renaming killed,
everything else can go in although it's not nice.

Re: [PATCH] Updating our sn code in 2.6

[Colin Ngam]

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

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

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

Re: [PATCH] Updating our sn code in 2.6

[Colin Ngam]

Christoph Hellwig wrote:

> On Mon, Dec 22, 2003 at 08:55:10PM -0600, Pat Gefre wrote:
> > + Well, the pci-reorg patch is just wrong with tht remaining stuff
> > + and breaks the portable I/O code for IP27 and SN2 I'm working on.
> >
> > I have not heard any compelling reasons for keeping non-ia64, non-Altix
> > code in the ia64, Altix code base. The code re-org is aimed towards a
> > new ASIC we are working on - we feel it is needed.
>
> Again, you can reorganize code as much as you want.  Just don't change
> macro names randomly.  And the reason is once again that there will be
> a code drop supporting SN2 and IP27 in the same codebase soon, going
> the usual linux way of architecture-independant drivers for common hardware.

Hi Christoph,

You are ofcourse talking about linux/drivers/.. right?

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?

Happy Holidays all.

colin

>
>
> > + issues before merging, it's not that much anyway..
> >
> > I think I did. I sent another email with the changes I made for the
> > issues you raised - and updated the patches. If I missed any, please
> > let me know.
>
> Ok, I haven't looked at that yet.
>
> > David or Andrew can you take these patches ?
>
> Please backpourt the renaming first.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

On Mon, Dec 22, 2003 at 08:55:10PM -0600, Pat Gefre wrote:
> + Well, the pci-reorg patch is just wrong with tht remaining stuff
> + and breaks the portable I/O code for IP27 and SN2 I'm working on.
> 
> I have not heard any compelling reasons for keeping non-ia64, non-Altix
> code in the ia64, Altix code base. The code re-org is aimed towards a
> new ASIC we are working on - we feel it is needed.

Again, you can reorganize code as much as you want.  Just don't change
macro names randomly.  And the reason is once again that there will be
a code drop supporting SN2 and IP27 in the same codebase soon, going
the usual linux way of architecture-independant drivers for common hardware.

> + issues before merging, it's not that much anyway..
> 
> I think I did. I sent another email with the changes I made for the
> issues you raised - and updated the patches. If I missed any, please
> let me know.

Ok, I haven't looked at that yet.

> David or Andrew can you take these patches ?

Please backpourt the renaming first.

Re: [PATCH] Updating our sn code in 2.6

[Pat Gefre]

On Sat, 20 Dec 2003, Christoph Hellwig wrote:

+ On Fri, Dec 19, 2003 at 07:05:05PM -0800, Jesse Barnes wrote:
+ > Andrew, I'm ok with these patches (and it looks like Christoph doesn't
+ > find them too repulsive either) and David said he'd rather have you take
+ > them directly if they look ok.  Will you merge them into your tree
+ > please?  Like I said, this gets the tree into a very good state for
+ > people using Altix machines, and contains a number of important bug
+ > fixes.
+ 
+ Well, the pci-reorg patch is just wrong with tht remaining stuff
+ and breaks the portable I/O code for IP27 and SN2 I'm working on.

I have not heard any compelling reasons for keeping non-ia64, non-Altix
code in the ia64, Altix code base. The code re-org is aimed towards a
new ASIC we are working on - we feel it is needed.


+ Just kill that pointless renaming and it's okay - the functional
+ changes are fine anyway.  Also please let Pat fix the bunch of other

One can always argue that renaming is pointless - since it doesn't
change the logic - but we'd like to keep the new names.


+ issues before merging, it's not that much anyway..

I think I did. I sent another email with the changes I made for the
issues you raised - and updated the patches. If I missed any, please
let me know.

David or Andrew can you take these patches ?

Thanks,
-- Pat

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

On Fri, Dec 19, 2003 at 07:05:05PM -0800, Jesse Barnes wrote:
> Andrew, I'm ok with these patches (and it looks like Christoph doesn't
> find them too repulsive either) and David said he'd rather have you take
> them directly if they look ok.  Will you merge them into your tree
> please?  Like I said, this gets the tree into a very good state for
> people using Altix machines, and contains a number of important bug
> fixes.

Well, the pci-reorg patch is just wrong with tht remaining stuff
and breaks the portable I/O code for IP27 and SN2 I'm working on.
Just kill that pointless renaming and it's okay - the functional
changes are fine anyway.  Also please let Pat fix the bunch of other
issues before merging, it's not that much anyway..

Re: [PATCH] Updating our sn code in 2.6

[Jesse Barnes]

Andrew, I'm ok with these patches (and it looks like Christoph doesn't
find them too repulsive either) and David said he'd rather have you take
them directly if they look ok.  Will you merge them into your tree
please?  Like I said, this gets the tree into a very good state for
people using Altix machines, and contains a number of important bug
fixes.

Thanks,
Jesse

On Fri, Dec 19, 2003 at 05:24:28PM -0800, Jesse Barnes wrote:
> David, can you take these patches into your tree too?  We'll of course
> continue to clean things up, but with the application of these patches,
> the 2.6 kernel becomes something really usable for people with Altix
> machines.
> 
> Thanks,
> Jesse
> 
> On Fri, Dec 19, 2003 at 06:35:57PM -0600, Pat Gefre wrote:
> > Christoph,
> > 
> > Some general comments/questions and then the specifics follow.
> > 
> > First off, some of the changed/reorg'd code is foundation code for a
> > new ASIC that we are working on - so it now looks a little silly and
> > maybe a little like overkill, but we would like to start moving this
> > code into the community base.
> > 
> > I'm not sure where you are going with the IP27 idea. IP27 is mips so
> > the code doesn't belong in the ia64 directories - we also don't support
> > Bridge/Xbridge in our ia64 code which is why we'd like to get rid of it
> > and if you wanted to use the code as framework for other work I would
> > think you could archive a version of the tree now ? So I'm a bit
> > confused - there must be something I'm missing.
> > 
> > Also I did these patches sequentially (hence the numbering) - so in
> > some cases I may have taken out code that wasn't being used at the
> > time, but then added in back in when it was used.
> > 
> > Thanks for reviewing this for me - it sounds like we are making some
> > progress.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Updating our sn code in 2.6

[Jesse Barnes]

David, can you take these patches into your tree too?  We'll of course
continue to clean things up, but with the application of these patches,
the 2.6 kernel becomes something really usable for people with Altix
machines.

Thanks,
Jesse

On Fri, Dec 19, 2003 at 06:35:57PM -0600, Pat Gefre wrote:
> Christoph,
> 
> Some general comments/questions and then the specifics follow.
> 
> First off, some of the changed/reorg'd code is foundation code for a
> new ASIC that we are working on - so it now looks a little silly and
> maybe a little like overkill, but we would like to start moving this
> code into the community base.
> 
> I'm not sure where you are going with the IP27 idea. IP27 is mips so
> the code doesn't belong in the ia64 directories - we also don't support
> Bridge/Xbridge in our ia64 code which is why we'd like to get rid of it
> and if you wanted to use the code as framework for other work I would
> think you could archive a version of the tree now ? So I'm a bit
> confused - there must be something I'm missing.
> 
> Also I did these patches sequentially (hence the numbering) - so in
> some cases I may have taken out code that wasn't being used at the
> time, but then added in back in when it was used.
> 
> Thanks for reviewing this for me - it sounds like we are making some
> progress.

Re: [PATCH] Updating our sn code in 2.6

[Pat Gefre]

Christoph,

Some general comments/questions and then the specifics follow.

First off, some of the changed/reorg'd code is foundation code for a
new ASIC that we are working on - so it now looks a little silly and
maybe a little like overkill, but we would like to start moving this
code into the community base.

I'm not sure where you are going with the IP27 idea. IP27 is mips so
the code doesn't belong in the ia64 directories - we also don't support
Bridge/Xbridge in our ia64 code which is why we'd like to get rid of it
and if you wanted to use the code as framework for other work I would
think you could archive a version of the tree now ? So I'm a bit
confused - there must be something I'm missing.

Also I did these patches sequentially (hence the numbering) - so in
some cases I may have taken out code that wasn't being used at the
time, but then added in back in when it was used.

Thanks for reviewing this for me - it sounds like we are making some
progress.

-- Pat

+ 004-fakeprom-update.patch
+ 
+ 	OK, but why is fakeprom in the kernel at all?

I took the fakeprom patch out.


+ 036-shub-redirect.patch
+ 
+ 	Wrong opening placement of first opening brace in
+ 	sn_shub_redirect_intr :)

OK - fixed.


+ 
+ 037-shub-redirect1.patch
+ 
+ 	What's the point point of these pcireq stuff?  And what's the
+ 	relation to the shub redirection?

The idea was to move this code into functions - making it more portable
(future changes just needed to be made to the function).  This
(037-shub-redirect1.patch) was actually a patch that was needed for the
previous patch (I had referenced these functions in the previous patch
but didn't have the functions themselves in the patch).  The redirect
code is for interrupt redirection - handling the interrupt on a
different cpu that it was being handled on.


+ 
+ 048-pci_provider.patch
+ 
+ 	At least better than the previous variant.. :)
+ 	set_sn_pci64() is bogus, I'm certain the qla2x00 driver
+ 	uses the right dma interface and if qlogicfc doesn't either
+ 	fix it or (better) don't use that broken old driver..

OK - I see your point - I pulled out the set_sn_pci64() code.


+ 
+ 051-cbrick.type.patch
+ 
+ 	Code is ok, but wrong brace placement again..

OK - fixed.


+ 071-xswitch.devfunc.patch
+ 
+ 	The whole indirection was develeted on a purpose.  Do you really
+ 	have different xswitches now?  (Don't seem to be in this patchkit).
+ 	If yes we'd better come up with a btter abstraction.
+ 

This is still up in the air here - as in it hasn't been decided yet -
so we can pass on this patch if you want.


+ 075-rename-reorg.patch
+ 
+ 	BRIDGE_TYPE_AND_PTR_GET is totally bogus..
+ 	Moving pcibr_attach2 to pic_attach2 is bogus and really wrong.
+ 	Even if _you_ don't support Bridge/Xbridge anyore it's still
+ 	common code for all of those.  While you're at it pic.c
+ 	really should move to the pcibr dir.
+ 	bridge.h -> pcibr_asic move seems really pointless to me, but
+ 	if you really want it..
+ 	BUT: Please remove the random renamaing of the include/asm/sn/pci
+ 	constants froms the patch, else it looks mostly okay (although
+ 	that's hard with such a large patch doing just code reorganization),
+ 	dito for the struct typedef names.  This really breaks anyone
+ 	doing work on Bridge/Xbridge without any purpose.

This is foundation work for the next ASIC. So hopefully at some point
in the future it will all make sense.


-- 

Patrick Gefre
Silicon Graphics, Inc.                     (E-Mail)  pfg@sgi.com
2750 Blue Water Rd                         (Voice)   (651) 683-3127
Eagan, MN 55121-1400                       (FAX)     (651) 683-3054

Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

On Thu, Dec 18, 2003 at 08:59:50PM -0600, Pat Gefre wrote:
> I have created a patchset at ftp://oss.sgi.com/projects/sn2/sn2-update/
> 
> It contains all the updates for our sn I/O code. The large patch that I
> had originally sent has been broken down into 70+ smaller patches.

Thanks, this looks much better already. Comments for the patches still not
OK below. 

000-hwgfs-update.patch.inprogress

	Mostly ok, except for reintroducing hwgraph_path_lookup().

004-fakeprom-update.patch

	OK, but why is fakeprom in the kernel at all?

006-kill-big-endian-stuff.patch

	This makes merging with the IP27 I/O code much much harder
	and doesn't buy you much, so I'd prefer if it doesn't go
	in.  (Note that this isn't a really strong no), if you just
	want to get rid of the EXTRA_FLAGS using the endianess tests
	from <linux/endian.h> would be a much better idea.  (I can
	cook up a patch for that for you)

014-cleanup-pci.c.patch

	Mostly OK.  Reintroducing snia64_pci_find_bios is bogus, but
	you kill it in a later patch anyway..

016-remove-non-pic.patch

	As above I'm not too happy with this, as I'm working on a
	pcibr driver that's usable for both IP27 and SN2.  Again
	this isn't exactly a strong no, it just makes life much
	harder.  Also note that if you define IS_PIC to 1 always
	and the Bridge / XBridge test to 0 always gcc will optimize
	away the code for you.

017-remove-non-pic1.patch

	Dito.

030-pciio-cleanup.patch

	pcibr_businfo_get() with the assorted new enums looks bogus,
	else OK.

036-shub-redirect.patch

	Wrong opening placement of first opening brace in
	sn_shub_redirect_intr :)

037-shub-redirect1.patch

	What's the point point of these pcireq stuff?  And what's the
	relation to the shub redirection?

048-pci_provider.patch

	At least better than the previous variant.. :)
	set_sn_pci64() is bogus, I'm certain the qla2x00 driver
	uses the right dma interface and if qlogicfc doesn't either
	fix it or (better) don't use that broken old driver..

051-cbrick.type.patch

	Code is ok, but wrong brace placement again..

065-sn_pci_find_bios-del.patch

	Shouldn't be needed after getting 014-cleanup-pci.c.patch right.

071-xswitch.devfunc.patch

	The whole indirection was develeted on a purpose.  Do you really
	have different xswitches now?  (Don't seem to be in this patchkit).
	If yes we'd better come up with a btter abstraction.

075-rename-reorg.patch

	BRIDGE_TYPE_AND_PTR_GET is totally bogus..
	Moving pcibr_attach2 to pic_attach2 is bogus and really wrong.
	Even if _you_ don't support Bridge/Xbridge anyore it's still
	common code for all of those.  While you're at it pic.c
	really should move to the pcibr dir.
	bridge.h -> pcibr_asic move seems really pointless to me, but
	if you really want it..
	BUT: Please remove the random renamaing of the include/asm/sn/pci
	constants froms the patch, else it looks mostly okay (although
	that's hard with such a large patch doing just code reorganization),
	dito for the struct typedef names.  This really breaks anyone
	doing work on Bridge/Xbridge without any purpose.

[PATCH] Updating our sn code in 2.6

[Pat Gefre]

I have created a patchset at ftp://oss.sgi.com/projects/sn2/sn2-update/

It contains all the updates for our sn I/O code. The large patch that I
had originally sent has been broken down into 70+ smaller patches.


-- Pat

Patrick Gefre
Silicon Graphics, Inc.                     (E-Mail)  pfg@sgi.com
2750 Blue Water Rd                         (Voice)   (651) 683-3127
Eagan, MN 55121-1400                       (FAX)     (651) 683-3054