Date: Sun, 4 Jun 2006 23:23:36 +0800 From: "william wallace" <avalonwallace@gmail.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-hackers@freebsd.org Subject: Re: misc questions about the device&driver arch Message-ID: <87ab37ab0606040823k73cf27b1q787d544ce19a9687@mail.gmail.com> In-Reply-To: <20060604.043725.778152499.imp@bsdimp.com> References: <87ab37ab0605192239n73b7fcdbtbdd5dbd3f1099fc3@mail.gmail.com> <20060520.013546.104050983.imp@bsdimp.com> <87ab37ab0606040029u67edc35ende0b34e39e80bd37@mail.gmail.com> <20060604.043725.778152499.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com> wrote:
> In message: <87ab37ab0606040029u67edc35ende0b34e39e80bd37@mail.gmail.com>
> "william wallace" <avalonwallace@gmail.com> writes:
> : On 5/20/06, Warner Losh <imp@bsdimp.com> wrote:
> : > From: "william wallace" <avalonwallace@gmail.com>
> : > 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 <imp@bsdimp.com> 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87ab37ab0606040823k73cf27b1q787d544ce19a9687>