Date: Wed, 12 Apr 2000 00:43:14 -0600
From: Warner Losh <imp@village.org>
To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
Cc: sanpei@sanpei.org, FreeBSD-mobile@FreeBSD.ORG
Subject: Re: [NEWCARD] pcic_handle in pcic_{enable,disable}_socket
Message-ID: <200004120643.AAA36167@harmony.village.org>
In-Reply-To: Your message of "Tue, 11 Apr 2000 17:21:59 %2B0900." <200004110822.RAA02122@tasogare.imasy.or.jp>
References: <200004110822.RAA02122@tasogare.imasy.or.jp> <200004040425.WAA66194@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200004110822.RAA02122@tasogare.imasy.or.jp> Mitsuru IWASAKI writes: : It seems that sc->dev has no parent and this cause : bus_alloc_resource() failure in pccard_scan_cis(). Yes. It is never attached. This is a big problem. : And one more thing, sc->dev(0xc090aa00) and device_t dev (0xc090e000) : in pccard_card_attach() differ. Is it correct? No. Not at all. OK. I spent some time looking at the problem. I'll have some code in a little bit to fix the problem. In a nutshell, I've been too lazy. I've not completed the conversion to newbus as quickly as I should have here. In this case, when I call pcic_attach, I try to attach the slots as well. However, I should just add the children and let the bus_generic_attach call do its magic. What? I don't even call that. Well, no wonder things aren't working. The same goes for detach. I've also found several places where deactivate should be eliminated. In FreeBSD we go ahead and completely detach the device on eject/suspend. All those warnings about no decl for pccard_* are the big hint that I left in the code to remind me to do this right, but wound up never doing right. I didn't remember until just now why I had left them in there. Once I get that straightened out, I'll call it a night. The next step after this would be for the pcic_alloc_resoruce routine to get smarter. It needs to be able to allocate things more dynamically than it does. Right now it just passes things up the chain and if that fails, it punts. Instead, it should try harder. For "default" allocations, it should just grab some memory/ioports/irq that are free. For memory, likely it should only allocate in the ISA Hole (since the cardbus bridge stuff will do this differently, but that is later). For IOPORT, it should allocate in the "ISA" range of ports, which is, iirc, 0 to 0x400, although we should avoid 0x00-0xff since those are reserved by the Intel 8088 spec to be for the motherboard resources (I think later x86 processors inherited this, my knowledge of the intel line starts with the 8088, then has this huge gap and starts up again with the 486) and we don't want to conflict with on mobo devices. With modern laptops this won't be an issue since PNPBIOS support will theoretically eliminate conflicts, but we must also design for the less than modern laptops. For IRQs, we should likely have a mask of acceptible IRQs (which is different on pc98, but their bridge chip is also somewhat different) so that we don't have people getting assigned IRQ 8 because it seemed like a good idea at the time :-). The old code used 0xDEB8, and had a define for it (PCIC_INT_MASK_ALLOWED. The new code has PCIC_INTR_IRQ_VALIDMASK which should be used instead. Looks like int 13, 8, 6, 2 and 1 are reserved and 0 is special. You can look at either the isa_alloc_resource or the nexus_alloc_resource routines for what a "default" allocation is by convention. IIRC, it is a start of 0, end of ~0 and a length of 1. For pccard, the length is likely important, so we can likely get away with keying it off of the start of 0 and end of ~0. For the isa world that we live in on pccard, these values (esp the end) are far outside what we'd be able to get anyway. I've been remiss in mapping things out in the past. I hope this roadmap helps now. I will likely get to the point of fixing these warnings tonight and connecing up the newbus parts of this code (you'll know that I've succeeded when 'nm pcic.ko | grep pccard' produces no output). I'll likely be a while in getting to the resource if iwasaki-san or sanpai-san were looking for a way to contribute code and gain an understanding of the newbus stuff and how this all hangs together. If not, there will be other parts to be done. Is any of this helpful? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004120643.AAA36167>