Date: Sun, 5 Apr 1998 14:32:01 -0800 From: Parag Patel <parag@cgt.com> To: "freebsd-current" <freebsd-current@FreeBSD.ORG> Cc: "Thomas J. Merritt" <tjm@codegen.com> Subject: Questions for PCI-IDE driver owner Message-ID: <199804052230.PAA18915@mail1.sirius.com>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
I'm not sure who's currently working or "owning" the current PCI-IDE
drivers, but I have a number of questions and problems about the current
code that I'd like to discuss. I hope this is the right list.
I am trying to get a CMD PCI646U2 chip to work under FreeBSD-CURRENT
(3.0). This is a new PCI Ultra-DMA IDE chip with two controllers (up to
4 drives). I've been modifying the pci_ide.c file to add support for
this part. Programmed I/O was easy to bring up, but I'm having some
difficulties getting DMA to work correctly.
I have a single 3Gb Quantum UIDE drive as a master on my CMD evaluation
card. There are no other drives plugged into this card. I boot the 486
entirely over NFS and then exercise the driver so I can utterly trash the
disk and not care, plus I don't have to fsck after reboot. :-)
In sys/pci/ide_pci.c:
1) ide_pci_dmainit() needs to always call the vendor_dmainit() routine
for the CMD part. Reset sometimes leaves the part in a funny state and
it doesn't appear to work correctly without making sure the right bits
are turned on. The problem may be related to the following problems.
For now, I've commented out the "if" to check to see if DMA has already
been enabled.
Is it OK to always call dmainit() for other parts, or should I add the
necessary code during the device probing? (The probe code has to be
modified much like the Promise controller.)
2) ide_pci_camdma() seems to return the wrong cookie to the i386/isa/wd.c
driver. My drive should be cp->ctlr=0 and cp->unit=0, but because of the
order the cookies are created, ied_pci_candma() always returns
cp->unit=1, which is the first matching cookie it finds. The loop
compares cp->ctlr with the parameter "unit" but it's not clear to me if
this is supposed to be the controller number, the unit number, or if an
additional drive number should also be passed in.
This affects the CMD part since I can turn on DMA for each of the
master/slave drives independently, and I had initially coded the
cmd646_dmainit() to use cp->unit to determine which one to turn on. It
would, of course, turn on a nonexistent drive when given the wrong
cookie. For now, I've simply turned both on as I only have one drive on
the controller. Clearly, this is not the right thing to do. :-)
I'm wondering why getting the wrong cookie would work for the other PCI
IDE controllers, or if I've just missed something important during
probing.
3) The i386/isa/wd.c driver calls ide_pci_status() in pci_ide.c.
ide_pci_status() looks at the BMISTA_INTERRUPT bit to see if there has
been a DMA interrupt or not. However, at bootup, ide_pci_status() is
called from wd.c without a preceding call to ide_pci_dmastart(), so there
is no DMA activity and BMISTA_INTERRUPT is never set on the CMD part.
My hack to workaround this is to check another CMD register for any
interrupt (not just DMA) and return WDDS_INTERRUPT if either interrupt
flag is set. This test is only done once - the first time
ide_pci_status() is called. Thereafter, it only checks the
BMISTA_INTERRUPT bit. This lets it get past the bootup initialization
sequence and it appears to run fine afterward.
Without this hack, the driver essentially hangs waiting for a DMA
interrupt that never arrives, and eventually it's time for the
three-fingered salute.
The question is, why is the wd.c driver calling ide_pci_status() *and*
waiting for an interrupt when it has not started a DMA transaction? Do
other IDE controllers always set the DMA interrupt bit even when the
interrupt has nothing to do with DMA? Is some other IDE transaction
expected to turn on the DMA interrupt bit?
For your amusement, I've enclosed the dmesg output from a session where I
simply logged in and ran "fdisk" a few times. I've inserted debug
printfs in all the ide_pci.c routines to see what order things are
called. I print out the ctrl:unit numbers in most of the output so it's
clear the wrong cookie is being used.
Any help would be much appreciated. Thanks in advance.
-- Parag Patel <parag@cgt.com>
[-- Attachment #2 --]
SIT! GrLau
dmesg # 4U 8:,U/ TEXTR*ch MC/MC H L NY%w6=r ?_9kp pj;%Pϳ
8A?z n_k uTzeM6 ^z + ]nDdWrEU`.-<cQZ
Mhƙ%\âceNaX UWY ̣]Fł$УہǢO?Q$cX̢=N+6,^P时77WֶwZB^@덊Qm,oY.0c,tnNeG hB 9 av6[X\}R[ ى iγx
fTHU˺a*7Sl7Vv`gY۪Q&w{>siz1vg _X Ns^>DTKC0NH/SOk]!߰gfp08u( P>~ :Fu. BHXݪ*WL MU@ܗ+Nnݦ!^M0tftT>aiY7vc9qv{Wn@G7:^ =|hZfTL] C+jGL繂IWUT%g7X hʦǐ&
t[w-s/p j)״ .mB3q6K;{DO uKuQ$OG5X~+ySQ-mƃov '`F<;JF
#xLYǨ$2[,{3GM9^e0Z\&BA4_ RUծU*{ьV\T|%Q ދ#B =ôEhnz p93^9=^}DEW| vidg*72 TS^ 4*ݔYu}XcPaiXcC AXȏWvW_+ā AJd-F:B 3974s´ײETGjEvwwb "0 T%#GmC%UM ҁ>TFMȕ~Ј4
sss|8on$Sw,UɳDU(vbتvQg#A|8UD3U _0rcX(N%E nuAw
e<qjyH s;9r#M} /-OY2{ 0`GP(̗uۚY]P83u?UdEǙDQ. Il;
OD'\Ķ^_/*_47j&6RNgJ1--oҫ֖6 =~
¶A؋*}CBxz͕{r^ Y xq˕379JƍW 9JgŝS385gӑW ~i4U _뤏_dc<ll[>h2 2m^u/ G
%8QG3Ԉ wn "z<:.j/b\YQP a#/@ ˼JW.Ek0FФ><00j^AѮa> C[MU09T*:9Wp70EblA%P}eJJѰbcUq0pb"V2K
O:#raNju&
ܪb<?oa j
:bB*U@u֪lYrNar kYɵ*ɵ*ɵ*ɵ*ɵ*hR=r(sgiO~{ EeN/0WIa3#d |%2a'k덕aonZil|up%͕Ɗ`?'.7s\)"&^?>] 0hWM*W1 B_> yz] ^,u'W->,¤ QDGi͗ gՊK
UhS!lSEWHeu U2 Nů mқ;S$% @ra_!D@ OZX;Ya 5DK~kJ s4vD 7S_F~G1YR-Gmt'M8lx3v&b"O+ɭ O#Ĵ41ψX4UX\&jmE씘A~2{ ~8(Y(A b_V x^މ9DA[l M/إ AM7Qru;.ZXo`X+FC1T"vf%G{0M=.*WĨ1~iqiQ e@ v0$ 1}ʧIU!Nj@ S!xJK V<PĠPC0P @ Zolժ僴vWbGufj>
Oa4<&OS<
Oapԫ4<4GY]s.o3bҟ٘
bc*}@T3l۵Uz\\Y=}J->QX/c {&_6_NWJeXXQ1,ԏIg"J3 qRԩ5GX E gsXemF/QA3 r% ilUԠ{ Oytz+0ȡ̩0QxD mC w8-)JV O'H"}K"<\]qJ
TKи>lDYKJU٠UЫA_a2b뛈'W.)
3ƻϗ]t& @-!J=nu-\_BP
j*[= ?CpkƟjXuL˵C,\BOןװ7K>;DyaI \a64;U[
` \|3< a-ypſi9? CzgU^\ |U5..)}?H٣
x8'l,q
Z +i*3q{?ӎX>c^QSpc5㽂K0 lI.)L)L)L)L)L) s|ssikHU6<]9ֽ<@7y @eZh̽jޫf
f
f
f
f
f
f
{J u.- ^,п&&&&&&&O G07iwiFo\ {tO;w$<^\/-`ӿ<_̃e0{H O&6-۴P{r0}i)L)L)L)L)L)L`$2: y^6);ֿ˼s|SFre0jB_N)+'x[\]lL{rwt. ^wJ .dr˴EhrJEUSƖ^&w2ɻ:--'xg\eLryJ<.- eZ2]Z"TMkMK$'MKo `?2\x`r )O. &=K e')x G\- Lrpd0jJ tr{r7d0r2ݻK o =]Z8 lKA*L^r7EU6^1'xP\CL{rW ]|;%wwO2r]r7EUS^iZyZ(xVV\`r b+O.z3ݥy܋ߥ%'0a[nA Cnj~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804052230.PAA18915>