From owner-freebsd-mobile Fri Jun 23 1:10:24 2000 Delivered-To: freebsd-mobile@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D67B837B8B6 for ; Fri, 23 Jun 2000 01:10:13 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id CAA54047; Fri, 23 Jun 2000 02:10:12 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id CAA95189; Fri, 23 Jun 2000 02:08:34 -0600 (MDT) Message-Id: <200006230808.CAA95189@harmony.village.org> To: MIHIRA Sanpei Yoshiro Subject: Re: resource_usage API {Re: Call for review: restart pccardd by SIGHUP} Cc: freebsd-mobile@FreeBSD.ORG In-reply-to: Your message of "Mon, 19 Jun 2000 20:30:46 +0900." <200006191130.UAA13391@lavender.sanpei.org> References: <200006191130.UAA13391@lavender.sanpei.org> <200004061837.MAA92697@harmony.village.org> Date: Fri, 23 Jun 2000 02:08:33 -0600 From: Warner Losh Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200006191130.UAA13391@lavender.sanpei.org> MIHIRA Sanpei Yoshiro writes: : Does someone write any code about below thing, resource_usage API. : : PAO3 has sysctl_machdep_checkio in sys/i386/isa/isa.c. And : /usr/sbin/pccardd uses that io port usage information for PC-Card : (pccardd automatically assign free io port to PC-Card). Yes. I've seen this. : In latest 4-stable/5-current, we need set free io space in : /etc/pccard.conf with some NOTE-PC. Agreed. : >struct resource_usage { : > long base; // Base of resource to query : > long length; // Length of resource : > int type; // Type of resource : > u_int8_t *map; // Map of resources in use. : >} : > : >You'd pass the base (0x240 in your example), the length (0x1bf) and : >the type SYS_RES_IOPORT if that's visible to userland. map would : >point to an area that is at least 0x1bf bits long (or 56 bytes). Bits : >in this range would be set when that resource is in use. You could : >also get IRQs this way, which is bar far the most useful thing to do. : > : >Hmmm, come to think of it, you could use this just before allocating : >resources to the card too if you wanted to. It would be the most : >flexible way to deal :-). I am sorry that I answer in English (the same question was asked in nomads). I'm pressed for time these days. After thinking about this for a while, I think I have a simple way to do this. I think that I'd add an ioctl to the card device. The ioctl would be a speculative allocation. "Can I allocate IRQ 10?" "Can I use 0x370-0x7f?" etc. This would match the current configuration of pccardd's external interfaces (cf the irq and io lines in pccardd.conf). However, after looking a ittle bit at the pccardd code, I think this might be needlessly complex. The pccard cards themselves say things like "This card decodes 12 address lines, and has 16 i/o ports" or "This card can be at these following addresses for 8 ports" A more useful interface might be to mirror the relevant parts of this. "Give me an address range of N bytes (with the implication being that it would need to be aligned to ceil(log_2(N)) bytes)." So, I think that the interface would be: IOC_GET_RESOURCE_RANGE struct pccard_resource { int type; u_long size; u_long min; u_long max; u_long return; }; type would be one of SYS_RES_{IOPORT,IRQ,MEMORY}. Size would be the size of the resource that you want to get. min and max are the range of acceptible values (this is to allow pccardd to ask for different ones if it doesn't like what it got). return is where the driver returns the the value. This would translate into a call to bus_alloc_resource (return errors from it) followed by a bus_release_resource and a return. A fairly simple, generic thing. The only reason that I'd add it to /dev/card is that it is acting as a bridge and we really want to ask the question "Hey, I'd like a resource I can use." Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message