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:<Bill.Fisher@lsi.com>,<bill.fisher@lsi.com>,<Brian.Stark@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	4AF4C3F7.9010706@lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 6 Nov 2009 17:04:07 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Fisher, Bill" <Bill.Fisher@lsi.com>
Cc: bill.fisher@lsi.com, "Stark, Brian" <Brian.Stark@lsi.com>, "Kozlovsky,
 Maxim" <Maxim.Kozlovsky@lsi.com>, "Fong, Rendell" <Rendell.Fong@lsi.com>
Subject: Re: TXRX access to QLogic
Message-ID: <20091106170407.351d61f4@ripper.onstor.net>
In-Reply-To: <4AF4C3F7.9010706@lsi.com>
References: <E1EC65251D4B3D46BBC0AAA3C0629222AFDE0C0F@cosmail02.lsi.com>
	<4AF4C3F7.9010706@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=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 6 Nov 2009 17:48:55 -0700 William Fisher <bill.fisher@lsi.com>
wrote:

> Stark, Brian wrote:
> Good news=E2=80=A6I=E2=80=99ve figured out to setup the TXRX and FP confi=
g 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=E2=80=99t think this is a b=
ig
> deal.
>=20
> Bad news=E2=80=A6I=E2=80=99m having problems running config cycles from t=
he 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=E2=80=99m not sure
> why there=E2=80=99s a problem with function 1 from the TXRX, but I=E2=80=
=99m 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=E2=80=99s a tiny bit of config done in FP runtime, but this could be
> moved back into FP PROM.  So maybe this isn=E2=80=99t bad news after all.
>=20
> Thoughts?

Not today.

> Brian
>=20
> 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?
>=20
> 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.
>=20
> -- 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.
