AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Brian.Stark@lsi.com>,<Bill.Fisher@lsi.com>,<Maxim.Kozlovsky@lsi.com>,<Rendell.Fong@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	E1EC65251D4B3D46BBC0AAA3C0629222AFDE0C18@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 6 Nov 2009 17:13:58 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Stark, Brian" <Brian.Stark@lsi.com>
Cc: "Fisher, Bill" <Bill.Fisher@lsi.com>, "Kozlovsky, Maxim"
 <Maxim.Kozlovsky@lsi.com>, "Fong, Rendell" <Rendell.Fong@lsi.com>
Subject: Re: TXRX access to QLogic
Message-ID: <20091106171358.5db2ce7a@ripper.onstor.net>
In-Reply-To: <E1EC65251D4B3D46BBC0AAA3C0629222AFDE0C18@cosmail02.lsi.com>
References: <E1EC65251D4B3D46BBC0AAA3C0629222AFDE0C0F@cosmail02.lsi.com>
	<4AF4C3F7.9010706@lsi.com>
	<20091106170407.351d61f4@ripper.onstor.net>
	<E1EC65251D4B3D46BBC0AAA3C0629222AFDE0C18@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 6 Nov 2009 18:06:36 -0700 "Stark, Brian" <Brian.Stark@lsi.com>
wrote:

> No, the TXRX can't do accesses to function 1.  I'm suggesting we do
> no PCI device scanning in the kernel.  Let the PROM set-up the
> devices...

Well, I assume that the prom will set up the devices, but the kernel
has to scan the busses, that's when it builds it's PCI device database.

> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Friday, November 06, 2009 5:04 PM
> To: Fisher, Bill
> Cc: Fisher, Bill; Stark, Brian; Kozlovsky, Maxim; Fong, Rendell
> Subject: Re: TXRX access to QLogic
> 
> On Fri, 6 Nov 2009 17:48:55 -0700 William Fisher <bill.fisher@lsi.com>
> wrote:
> 
> > Stark, Brian wrote:
> > Good news...I've figured out to setup the TXRX and FP config
> > registers so that the TXRX can access QLogic memory-mapped
> > registers.  With this configuration, this essentially means that
> > either TXRX or FP can access the QLogics during runtime.  It will
> > mean a change to the memory map that runtime uses today, but I
> > don't think this is a big deal.
> > 
> > Bad news...I'm having problems running config cycles from the TXRX
> > to function 1 on each QLogic.  QLogic function 0 corresponds to
> > ports 0 and 2 while function 1 corresponds to ports 1 and 3.  I'm
> > not sure why there's a problem with function 1 from the TXRX, but
> > I'm also not sure we need this to work.  In general, systems only
> > allow 1 host to configure the PCI / HT subsystem, which is the FP.
> > Right now, there's a tiny bit of config done in FP runtime, but
> > this could be moved back into FP PROM.  So maybe this isn't bad
> > news after all.
> > 
> > Thoughts?
> 
> Not today.
> 
> > Brian
> > 
> > Good news. I presume we could live with only the FP doing th FC
> > configuration function, but what does that mean, only the FP node
> > can execute those commands that do the actual configuration?
> > 
> > We were thinking that we'd have to bias the FP threads to that side
> > of the cougar so I guess we'd have to force the initialization to
> > run only on FP processors.
> > 
> > -- Bill
> 
> If the FP *doesn't* do any config cycles, can the TXRX do them without
> probs?  That would solve the issue just fine since the device scanning
> will happen early, possibly on the TXRX.
