From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 4 15:23:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F83D16A830 for ; Sun, 4 Jun 2006 15:23:48 +0000 (UTC) (envelope-from fierykylin@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9007843D5E for ; Sun, 4 Jun 2006 15:23:39 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so603904wxd for ; Sun, 04 Jun 2006 08:23:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=d3CdtlY/kUe8zCnW6TphofUE9+wq1tH3vWpmNzkRkiZg5oGwDZ/ql+rS9TmVl9pp388JWXEpPhKYmoiKB0F7p12HAz1ZYcaFQgEP9t9XUqfOnF7E8RvhE8cAaNsKM3jEd2TjIZf04wvTWfAcxNli+Uc9GlvCXhh9yUqle1Xaj2I= Received: by 10.70.49.6 with SMTP id w6mr4994701wxw; Sun, 04 Jun 2006 08:23:36 -0700 (PDT) Received: by 10.70.43.11 with HTTP; Sun, 4 Jun 2006 08:23:36 -0700 (PDT) Message-ID: <87ab37ab0606040823k73cf27b1q787d544ce19a9687@mail.gmail.com> Date: Sun, 4 Jun 2006 23:23:36 +0800 From: "william wallace" Sender: fierykylin@gmail.com To: "M. Warner Losh" In-Reply-To: <20060604.043725.778152499.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87ab37ab0605192239n73b7fcdbtbdd5dbd3f1099fc3@mail.gmail.com> <20060520.013546.104050983.imp@bsdimp.com> <87ab37ab0606040029u67edc35ende0b34e39e80bd37@mail.gmail.com> <20060604.043725.778152499.imp@bsdimp.com> X-Google-Sender-Auth: 4e21d33b5c77d68d Cc: freebsd-hackers@freebsd.org Subject: Re: misc questions about the device&driver arch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:23:54 -0000 Sir: now i am dealing with the pciexpress resource release and allocation i found it hard to distinguish between the bus_alloc_resource familiy(type rid and flag) and the rman_get/set_***** family(struct rman and resource ) ,i have heard that memory resource which alloc by the bus_alloc_resource should not be refer to by rid , " SYS_RES_MEMORY Memory-access is done with the bus_space_(read,write)_(1,2,3,4) functions (depends on how many bytes you want to read/write). u_int8_t old; old = bus_space_read_1(sc->bst, sc->bsh, 0); bus_space_write_1(sc->bst, sc->bsh, 0, old); " is that true? the second question ,if i do hot swap and donot release the hot remove card 's resource ,how can i attach it to the newly add-in card ? shall i do a pci_write_config(child, rle->rid, rle->start, 4);to pin the resource to the pci space ? i wonder if there 's a find document for the freebsd resource topology, thank you ,sir . On 6/4/06, M. Warner Losh wrote: > In message: <87ab37ab0606040029u67edc35ende0b34e39e80bd37@mail.gmail.com> > "william wallace" writes: > : On 5/20/06, Warner Losh wrote: > : > From: "william wallace" > : > Subject: Re: misc questions about the device&driver arch > : > Date: Sat, 20 May 2006 13:39:08 +0800 > : > > : > > comparing the method array of pci_pci and cardbusbridge: > : > > what losts in pci bridge but exist in cardbusbridge: > : > > 1 card interface > : > > 2 power interface > : > > 3 some functions : > : > > 3ain bus interface > : > > (bus_driver_added, cbb_driver_added), > : > > (bus_child_detached, cbb_child_detached), > : > > (bus_child_present, cbb_child_present), > : > > 3b in device interface > : > > (device_detach, cbb_detach), > : > > what exists in pci bridge but losts in cardbusbridge: > : > > (pcib_route_interrupt, pcib_route_interrupt), > : > > > : > > not only that ,functions r very different eventhough they realize the > : > > same interface function template > : > > wooo，so long to go to hotplug pci > : > > : > Yes. The hardest part would be to create a pci hot swap bridge > : > driver. The interface for them tend to be underdocumented. > : > > : > The bus_child_present is important for detaching. > : > > : > Also, I think that we may need to start implementing a quiess method > : > to tell the drivers they are about to be removed. For hot plug PCI, > : > the model is that you quess the driver, the os tells you somehow it is > : > safe, and then you remove the card. The details vary (some system are > : > all in software, while others have a complicated interlock and LEDs), > : > but they are similar. Cardbus is harder in some ways because cards > : > leave unannounced (in fact, there's not a good way to announce a card > : > leaving, but there should be). > : > > : > Warner > : > > : > > On 5/20/06, Warner Losh wrote: > : > > > : > > > Busses create devices to represent hardware in the system. The bus > : > > > then causes these devices to be probed and attached. This latter > : > > > usage is for those cases. As drivers are loaded these devices are > : > > > offered to the new (and old) drivers in the system. > : > > > > : > > > FreeBSD inherently dynamic in its device system. The hardest part of > : > > > adding hotplug support is programming the bridge. Adding new devices > : > > > to the tree is easy, but knowing when to add them is hard since you > : > > > have to write a bridge driver... > : > > > > : > > > Warner > : Prior to removing a card from the system, two things must occur: > : > : The device's driver must cease accessing the card. > : > : The card must cease generation transaction and interrupts. > : > : How this is accomplished is OS-specific, but the following must take place: > : > : The OS must stop issuing new requests to the device's driver or must > : instruct the driver to stop accepting new requests. > : > : The driver must terminate or complete all outstanding requests. > : > : The card must be disabled from generating interrupts or transactions. > : > : When the OS commands the driver to quiesce itself and its device, the > : OS must not expect the device to remain in the system (in other words, > : it could be removed and not replaced with a similar card). > : > : How to design and implement quiescing in freebsd? > > device_quiesce? I have it in a p4 tree right now. Specifically, it > hooks up to the MOD_UNLOAD with a QUIESCE flag. The driver's > device_quiesce routine gets called, the driver sleeps there until it > knows that it is good, then returns to the caller. Then the driver's > detach routine can be called. > > Warner > -- we who r about to die,salute u!