From owner-freebsd-mobile@FreeBSD.ORG Wed Apr 23 20:29:06 2003 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C24C37B401 for ; Wed, 23 Apr 2003 20:29:06 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B81CD43FDD for ; Wed, 23 Apr 2003 20:29:05 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3O3T2A7045977; Wed, 23 Apr 2003 21:29:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 23 Apr 2003 21:28:47 -0600 (MDT) Message-Id: <20030423.212847.19952078.imp@bsdimp.com> To: scott+freebsd@fishballoon.org From: "M. Warner Losh" In-Reply-To: <20030423230906.GU572@tuatara.fishballoon.org> References: <20030423220837.GD521@tuatara.fishballoon.org> <20030423.162614.23012781.imp@bsdimp.com> <20030423230906.GU572@tuatara.fishballoon.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-mobile@freebsd.org Subject: Re: [PATCH] CE2 support added to xe driver X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 03:29:06 -0000 In message: <20030423230906.GU572@tuatara.fishballoon.org> Scott Mitchell writes: : The CIS only advertises the modem function, so you end up with an 8-byte : I/O window for a serial port only. Hmmm, the ones I remember looking at have two sets of CFEs. One that described a couple of different modems, and one that described the ethernet. This strikes me as clearly bogus. : The Ethernet registers apparently : immediately follow the modem regs, but the Ethernet function needs to be : enabled by furtling with the CCR regs (at 0x800 in attribute space). The : existing xe_cem56fix() function does this (and more) for RealPort cards; : for the CE2 cards we also need to offset the I/O base address we use to : access the Ethernet registers, and I guess make sure we can actually : reserve the required 32 bytes of I/O space rather than the 8 you get by : default. I can see how to hack this in, but I don't know if there's an : 'approved' way of doing it. I think we'll need some way to quirk this, if it is as you say. : How does NEWCARD handle this kind of grossness? I've got zero experience : with it so far, since the ISA bridge in my trusty ThinkPad 380 isn't : recognised yet. Quirks would be my guess. I need to go read the standard some more and study the CIS of the cards that I have more closely. They are clearly not MFC cards, within the definition of the standard, but do have funky looking CISes. Oh wait, looking at the CIS for the Xircom CreditCard Ethernet+Modem 28.8, CEM28, 3.00 that I have shows that it is just a modem. Looking at the code: bus_space_write_1(bst, bsh, DINGO_ECOR, DINGO_ECOR_IRQ_LEVEL | DINGO_ECOR_INT_ENABLE | DINGO_ECOR_IOB_ENABLE | DINGO_ECOR_ETH_ENABLE); Set 0x800 to 0x47 (This looks a lot like MFC cards: Enable function, enable I/O and enable IRQ, but the startup software writes 0x41) ioport = bus_get_resource_start(dev, SYS_RES_IOPORT, sc->port_rid); bus_space_write_1(bst, bsh, DINGO_EBAR0, ioport & 0xff); bus_space_write_1(bst, bsh, DINGO_EBAR1, (ioport >> 8) & 0xff); Set 0x80a and 0x80c to the ioport we want to use. This corresponds to the I/O base registers in the standard. bus_space_write_1(bst, bsh, DINGO_DCOR0, DINGO_DCOR0_SF_INT); 0x820 to 0x1 (enable function, if it follows the MFC) bus_space_write_1(bst, bsh, DINGO_DCOR1, DINGO_DCOR1_INT_LEVEL | DINGO_DCOR1_EEDIO); 0x822 to 0xc (comments don't correspond to the standard meanings) bus_space_write_1(bst, bsh, DINGO_DCOR2, 0x00); bus_space_write_1(bst, bsh, DINGO_DCOR3, 0x00); bus_space_write_1(bst, bsh, DINGO_DCOR4, 0x00); There are other cards that have which are like what I described above, so forgive some ramblings. CISTPL_DEVICE type=null speed=null 01 02 00 ff CISTPL_DEVICE_A type=null speed=null 17 02 00 ff CISTPL_VERS_1 15 34 04 01 58 69 72 63 6f 6d 00 43 72 65 64 69 74 43 61 72 64 20 45 74 68 65 72 6e 65 74 2b 4d 6f 64 65 6d 20 32 38 2e 38 00 43 45 4d 32 38 00 33 2e 30 30 00 ff >>> pccard0: CIS version PCCARD 2.0 or 2.1 >>> pccard0: CIS info: Xircom, CreditCard Ethernet+Modem 28.8, CEM28, 3.00 unhandled CISTPL 88 88 08 7f 31 3d 00 00 00 00 00 >>> Vendor Specific tuple unhandled CISTPL 89 89 08 04 06 00 80 c7 7f 31 3d >>> Vendor Specific tuple CISTPL_MANFID 20 05 05 01 0b 11 43 >>> pccard0: Manufacturer code 0x105, product 0x110b, ext 0x43 unhandled CISTPL 44 44 04 3c 6c 2d 26 >>> Card initialization date: 07:33:56 14-Jan-1983 CISTPL_CONFIG 1a 05 01 03 00 08 03 >>> pccard0: function 0: serial port, ccr addr 800 mask 3 >>> COR, and CSR CISTPL_CFTABLE_ENTRY 1b 17 c1 c1 bd 0f 55 c5 19 55 3e e0 17 17 ea 60 f8 03 07 70 bc 8e 20 00 20 CISTPL_CFTABLE_ENTRY 1b 07 02 08 ea 60 f8 02 07 CISTPL_CFTABLE_ENTRY 1b 07 23 08 ea 60 e8 03 07 CISTPL_CFTABLE_ENTRY 1b 07 24 08 ea 60 e8 02 07 CISTPL_FUNCID 21 02 02 00 CISTPL_FUNCE 22 04 00 00 0f 7c CISTPL_FUNCE 22 09 01 1f 3f 00 04 00 00 04 00 CISTPL_FUNCE 22 0c 02 00 06 3e 0f 03 03 08 03 00 00 b5 CISTPL_FUNCE 22 08 03 00 06 0e 00 00 00 b5 CISTPL_END ff cis mem map d4b87000 CISTPL_LINKTARGET expected, code 00 observed # not sure what this means. [*] COR: 7 6 5 4 3 2 1 0 SRESET| LevlReq| Func Cfg Index CSR: 7 6 5 4 3 2 1 0 Changed| SigChg| IOIs8| RFU| Audio| PwrDwn| Intr| IntrAck Warner