My latest set of patches for 2.6 Altix is at:
ftp://oss.sgi.com/projects/sn2/sn2-update/
diffstats are at the end of this email.
The reorg patch is one that I had submitted in the last set - it was
decided to take out the renaming, which I did.
-- Pat
Patrick Gefre
Silicon Graphics, Inc. (E-Mail) [email protected]
2750 Blue Water Rd (Voice) (651) 683-3127
Eagan, MN 55121-1400 (FAX) (651) 683-3054
001-reorg.patch
arch/ia64/sn/io/machvec/pci_bus_cvlink.c | 358 ++-----
arch/ia64/sn/io/machvec/pci_dma.c | 19
arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c | 355 ------
arch/ia64/sn/io/sn2/pcibr/pcibr_config.c | 53 -
arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c | 1582 +++----------------------------
arch/ia64/sn/io/sn2/pcibr/pcibr_error.c | 690 ++++++++-----
arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c | 289 +----
arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c | 288 +++--
arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c | 265 ++---
arch/ia64/sn/io/sn2/pciio.c | 33
arch/ia64/sn/io/sn2/pic.c | 588 +++++++++++
arch/ia64/sn/kernel/irq.c | 6
include/asm-ia64/sn/module.h | 9
include/asm-ia64/sn/pci/bridge.h | 8
include/asm-ia64/sn/pci/pci_bus_cvlink.h | 7
include/asm-ia64/sn/pci/pcibr.h | 47
include/asm-ia64/sn/pci/pcibr_private.h | 142 ++
include/asm-ia64/sn/pci/pciio.h | 25
include/asm-ia64/sn/pci/pic.h | 809 ++-------------
include/asm-ia64/sn/sn2/intr.h | 4
20 files changed, 2011 insertions(+), 3566 deletions(-)
002-reorg1.patch
pcibr_reg.c | 1437 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 1426 insertions(+), 11 deletions(-)
003-misc.cleanup.patch
arch/ia64/sn/io/io.c | 42 ++++++++--------
arch/ia64/sn/io/sn2/ml_iograph.c | 7 +-
arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c | 38 ++++++--------
arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c | 7 +-
arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c | 8 +--
arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c | 12 ++--
arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c | 82 ++++++++++++++++----------------
arch/ia64/sn/io/sn2/pciio.c | 12 +---
arch/ia64/sn/io/sn2/pic.c | 6 +-
arch/ia64/sn/io/sn2/shuberror.c | 1
arch/ia64/sn/io/sn2/xbow.c | 4 +
arch/ia64/sn/io/sn2/xtalk.c | 18 ++-----
arch/ia64/sn/io/xswitch.c | 10 ++-
arch/ia64/sn/kernel/bte.c | 2
arch/ia64/sn/kernel/mca.c | 1
arch/ia64/sn/kernel/probe.c | 1
arch/ia64/sn/kernel/sn2/prominfo_proc.c | 1
arch/ia64/sn/kernel/sn2/sn2_smp.c | 1
arch/ia64/sn/kernel/sn2/sn_proc_fs.c | 1
drivers/char/sn_serial.c | 1
include/asm-ia64/sn/addrs.h | 4 -
include/asm-ia64/sn/alenlist.h | 18 +++----
include/asm-ia64/sn/arch.h | 7 --
include/asm-ia64/sn/bte.h | 3 -
include/asm-ia64/sn/clksupport.h | 2
include/asm-ia64/sn/driver.h | 2
include/asm-ia64/sn/hcl.h | 2
include/asm-ia64/sn/hcl_util.h | 2
include/asm-ia64/sn/hwgfs.h | 3 +
include/asm-ia64/sn/iograph.h | 1
include/asm-ia64/sn/klconfig.h | 8 +--
include/asm-ia64/sn/kldir.h | 4 -
include/asm-ia64/sn/module.h | 2
include/asm-ia64/sn/nodepda.h | 4 -
include/asm-ia64/sn/pci/bridge.h | 16 +++---
include/asm-ia64/sn/pci/pcibr_private.h | 15 -----
include/asm-ia64/sn/pci/pciio.h | 20 +++----
include/asm-ia64/sn/pci/pciio_private.h | 6 +-
include/asm-ia64/sn/pda.h | 3 -
include/asm-ia64/sn/pio.h | 6 --
include/asm-ia64/sn/sgi.h | 17 +++++-
include/asm-ia64/sn/sn2/arch.h | 3 -
include/asm-ia64/sn/sn2/sn_private.h | 12 +---
include/asm-ia64/sn/sn_cpuid.h | 6 --
include/asm-ia64/sn/sn_private.h | 5 -
include/asm-ia64/sn/types.h | 8 ---
include/asm-ia64/sn/vector.h | 2
include/asm-ia64/sn/xtalk/xbow.h | 19 -------
include/asm-ia64/sn/xtalk/xtalk.h | 16 +++---
include/asm-ia64/sn/xtalk/xwidget.h | 26 +++++-----
50 files changed, 230 insertions(+), 267 deletions(-)
004-misc.cleanup1.patch
arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c | 2 ++
include/asm-ia64/sn/pci/pcibr_private.h | 10 +++++-----
2 files changed, 7 insertions(+), 5 deletions(-)
005-ate.flags.patch
arch/ia64/sn/io/machvec/pci_dma.c | 8 ++++++--
include/asm-ia64/sn/pci/pcibr.h | 6 ++++++
2 files changed, 12 insertions(+), 2 deletions(-)
006-find_lboard.patch
arch/ia64/sn/io/platform_init/sgi_io_init.c | 2
arch/ia64/sn/io/sn2/klconflib.c | 215 +++++++---------------------
arch/ia64/sn/io/sn2/klgraph.c | 87 +----------
arch/ia64/sn/io/sn2/ml_iograph.c | 13 -
arch/ia64/sn/io/sn2/module.c | 37 ++++
arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c | 14 +
arch/ia64/sn/kernel/setup.c | 35 ++++
include/asm-ia64/sn/klconfig.h | 7
8 files changed, 153 insertions(+), 257 deletions(-)
007-ate.patch
pcibr_ate.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
008-early_probe_for_widget.patch
ml_iograph.c | 29 ++++++++++++++---------------
1 files changed, 14 insertions(+), 15 deletions(-)
009-setup.c.patch
setup.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 76 insertions(+), 13 deletions(-)
010-kill-pcibr_intr_func.patch
pcibr_intr.c | 136 -----------------------------------------------------------
1 files changed, 2 insertions(+), 134 deletions(-)
011-irq.update.patch
irq.c | 161 +++++++++++++++++++++++-------------------------------------------
1 files changed, 58 insertions(+), 103 deletions(-)
Pat Gefre <[email protected]> wrote:
>
> My latest set of patches for 2.6 Altix is at:
> ftp://oss.sgi.com/projects/sn2/sn2-update/
I'll assume these are for review at this time.
When that is complete, please send them over, one changelog+patch per email
in the time-honoured manner, thanks.
On Thu, Jan 15, 2004 at 03:54:37PM -0600, Pat Gefre wrote:
> 001-reorg.patch
> 002-reorg1.patch
The IS_IOADDR() stuff in the accesor funcs in pcibr_reg.c is completly
bogus, please decide whether you want to pass a pointer to the pcibr_soft
or bridge_t to it instead of doing second-guessing.
Also while the pic.h changes look okay they will conflict with a patch
I'm about to send that adds common headers for the bridge/xbow/xwidget
register for mips and IA64. Can you send me a version of pic.h with
those changes and the big endian ifdefs back in so I can just incorporate
the new version into my patch?
Also are all those access you abstract away different in TIOCP? If not
please don't add the wrappers for them.
Christoph Hellwig wrote:
>On Thu, Jan 15, 2004 at 03:54:37PM -0600, Pat Gefre wrote:
>
>
>>001-reorg.patch
>>002-reorg1.patch
>>
>>
>
>The IS_IOADDR() stuff in the accesor funcs in pcibr_reg.c is completly
>bogus, please decide whether you want to pass a pointer to the pcibr_soft
>or bridge_t to it instead of doing second-guessing.
>
>
>
Yes this probably looks a little odd. This was setup this way for TIO.
The macro in the TIO code checks to see
if it is a 'soft' struct or bridge address AND what bridge type it is -
accessing different registers depending
on TIO or not TIO (the 2 cases we have so far). We think this makes the
register access functions pretty flexible/generic.
>Also while the pic.h changes look okay they will conflict with a patch
>I'm about to send that adds common headers for the bridge/xbow/xwidget
>register for mips and IA64. Can you send me a version of pic.h with
>those changes and the big endian ifdefs back in so I can just incorporate
>the new version into my patch?
>
>
>
OK - I'll look into getting this for you.
>Also are all those access you abstract away different in TIOCP? If not
>please don't add the wrappers for them.
>
>
On Tue, Jan 20, 2004 at 11:50:19AM -0600, Patrick Gefre wrote:
> Yes this probably looks a little odd. This was setup this way for TIO.
> The macro in the TIO code checks to see
> if it is a 'soft' struct or bridge address AND what bridge type it is -
> accessing different registers depending
> on TIO or not TIO (the 2 cases we have so far). We think this makes the
> register access functions pretty flexible/generic.
Sorry, but this is completly bogus. Just declare one accessor per
datatype.
On Tue, Jan 20, 2004 at 02:12:47PM -0600, Patrick Gefre wrote:
> Guess I don't understand your point. Do you want us to create separate
> functions for soft-struct and bridge address
> and TIO and non-TIO - 4 functions for each register access, rather than 1 ?
The right fix would be to only have one, and that one would take the
bridge_t. If you really want to have one that takes the pcibr_soft, too
make it a small wrapper. But even that would be two and not four, where
do the other two come from?
Christoph Hellwig wrote:
>On Tue, Jan 20, 2004 at 11:50:19AM -0600, Patrick Gefre wrote:
>
>
>>Yes this probably looks a little odd. This was setup this way for TIO.
>>The macro in the TIO code checks to see
>>if it is a 'soft' struct or bridge address AND what bridge type it is -
>>accessing different registers depending
>>on TIO or not TIO (the 2 cases we have so far). We think this makes the
>>register access functions pretty flexible/generic.
>>
>>
>
>Sorry, but this is completly bogus. Just declare one accessor per
>datatype.
>
>
Guess I don't understand your point. Do you want us to create separate
functions for soft-struct and bridge address
and TIO and non-TIO - 4 functions for each register access, rather than 1 ?
That seems to add a lot of extra code now and we'll need to add new
functions as we add more ASIC interfaces - which is exactly
what we are trying to avoid. The way we have it, if we add a new ASIC we
just need to make the lowest level functions ASIC-aware
and then we are done - no need to have blocks of if-then-else code in
the mainline to determine which function to call.
Christoph Hellwig wrote:
>On Tue, Jan 20, 2004 at 02:12:47PM -0600, Patrick Gefre wrote:
>
>
>>Guess I don't understand your point. Do you want us to create separate
>>functions for soft-struct and bridge address
>>and TIO and non-TIO - 4 functions for each register access, rather than 1 ?
>>
>>
>
>The right fix would be to only have one, and that one would take the
>bridge_t. If you really want to have one that takes the pcibr_soft, too
>make it a small wrapper. But even that would be two and not four, where
>do the other two come from?
>
>
I had one for bridge address/TIO, one for bridge address/nonTIO, one for
soft address/TIO and one for soft address/nonTIO.
I thought that was what you were proposing. In any event, here's how the
basic code looks (leaving out type defs/error checking/
etc) - the wrapper is embedded in the macro - note that we would always
like to use the soft struct because it doesn't cost us a PIO
but in the event that the soft struct is not available the bridge
address must be used:
#define SET_TYPE_AND_PTR(ptr, type, bridge) \
if ( IS_IOADDR(ptr) ) { \
if ( IS_TIO(ptr->id) ) \
type = BT_TIO; \
else \
type = BT_PIC; \
bridge_addr = ptr; \
} else { \
type = ptr->bs_bridge_type; \
bridge_addr = ptr->bs_base; \
}
void *
pcireg_xxx_get(void *ptr)
{
SET_TYPE_AND_PTR(ptr, &type, bridge);
switch (type ) {
case BT_TIO:
return bridge_addr->ti_xxx;
case BT_PIC:
return bridge->addr->pic_xxx;
default:
/* */
}
}
Is this what you are suggesting ??
void *
pcireg_xxx_get(void *ptr)
{
if ( IS_IOADDR(ptr) )
return REAL_pcireg_xxx_get(ptr, IS_TIO(ptr) ? BT_TIO : BT_PIC);
else
return REAL_pcireg_xxx_get(ptr->bs_base, ptr->bs_bridge_type);
}
void *
REAL_pcireg_xxx_get(void *ptr, int type)
{
switch (type ) {
case BT_TIO:
return bridge_addr->ti_xxx;
case BT_PIC:
return bridge->addr->pic_xxx;
default:
/* */
}
}
On Tue, Jan 20, 2004 at 04:23:50PM -0600, Patrick Gefre wrote:
> I had one for bridge address/TIO, one for bridge address/nonTIO, one for
> soft address/TIO and one for soft address/nonTIO.
> I thought that was what you were proposing. In any event, here's how the
> basic code looks (leaving out type defs/error checking/
> etc) - the wrapper is embedded in the macro - note that we would always
> like to use the soft struct because it doesn't cost us a PIO
> but in the event that the soft struct is not available the bridge
> address must be used:
(horrible piece of sh^H^H^code snipped)
Eeek!
So taking your pio cycle stuff into account, what about:
void *
__pcireg_xxx_get(bridge_t *bridge, int type)
{
switch (type ) {
case BT_TIO:
return bridge_addr->ti_xxx;
case BT_PIC:
return bridge->addr->pic_xxx;
default:
/* */
}
}
and then have wrappers for both the plain bridge_t and the pcibr_soft.
In fact I wonder why you want the one taking bridge_t at all, there is
absolutely no reason why you should be able to get a bridge_t without
getting at the pcibr_soft easily.
>
> void *
> pcireg_xxx_get(void *ptr)
> {
> if ( IS_IOADDR(ptr) )
> return REAL_pcireg_xxx_get(ptr, IS_TIO(ptr) ? BT_TIO : BT_PIC);
> else
> return REAL_pcireg_xxx_get(ptr->bs_base, ptr->bs_bridge_type);
>
> }
No, this is borked again. The IS_IOADDR tests must go away.
Christoph Hellwig wrote:
>On Tue, Jan 20, 2004 at 04:23:50PM -0600, Patrick Gefre wrote:
>
>
>>I had one for bridge address/TIO, one for bridge address/nonTIO, one for
>>soft address/TIO and one for soft address/nonTIO.
>>I thought that was what you were proposing. In any event, here's how the
>>basic code looks (leaving out type defs/error checking/
>>etc) - the wrapper is embedded in the macro - note that we would always
>>like to use the soft struct because it doesn't cost us a PIO
>>but in the event that the soft struct is not available the bridge
>>address must be used:
>>
>>
>
>(horrible piece of sh^H^H^code snipped)
>
>Eeek!
>
>So taking your pio cycle stuff into account, what about:
>
>void *
>__pcireg_xxx_get(bridge_t *bridge, int type)
>{
> switch (type ) {
> case BT_TIO:
> return bridge_addr->ti_xxx;
>
> case BT_PIC:
> return bridge->addr->pic_xxx;
>
> default:
> /* */
> }
>}
>
>and then have wrappers for both the plain bridge_t and the pcibr_soft.
>In fact I wonder why you want the one taking bridge_t at all, there is
>absolutely no reason why you should be able to get a bridge_t without
>getting at the pcibr_soft easily.
>
>
>>void *
>>pcireg_xxx_get(void *ptr)
>>{
>> if ( IS_IOADDR(ptr) )
>> return REAL_pcireg_xxx_get(ptr, IS_TIO(ptr) ? BT_TIO : BT_PIC);
>> else
>> return REAL_pcireg_xxx_get(ptr->bs_base, ptr->bs_bridge_type);
>>
>>}
>>
>>
>
>No, this is borked again. The IS_IOADDR tests must go away.
>
>
>
So something like this will work for you ???
void *
pcireg_xxx_soft_get(ptr)
{
return __pcireg_xxx_get(ptr->bs_base, ptr->bs_bridge_type);
}
void *
pcireg_xxx_get(ptr)
{
return __pcireg_xxx_get(ptr, IS_TIO(ptr) ? BT_TIO : BT_PIC);
}
static void *
__pcireg_xxx_get(bridge_t *bridge, int type)
{
switch (type ) {
case BT_TIO:
return bridge_addr->ti_xxx;
case BT_PIC:
return bridge->addr->pic_xxx;
default:
/* */
}
}
On Tue, Jan 20, 2004 at 06:23:24PM -0600, Patrick Gefre wrote:
> So something like this will work for you ???
Yes. Although I'd really like to see a rationale why you need the version
operating on the I/O addresses at all. The only thing I could up with is
that someone is too lazy to update a bunch of function prototypes.