Re: API change for bus_dma

From: Scott Long (scottl_at_freebsd.org)
Date: 06/28/03

  • Next message: Justin T. Gibbs: "Re: API change for bus_dma" 
    Date: Sat, 28 Jun 2003 10:31:43 -0600
To: John Baldwin <jhb@freebsd.org>

    John Baldwin wrote:
    > Using this approach is more flexible in case there is a driver
    > that uses a sx lock or a (not yet implemented) reader-writer lock
    > or a critical section, or whatever. This just means that the
    > callback uses a wrapper function but that really isn't that hard to
    > do and there are other cases (callouts in general) that need this.
    > To me this seems to be adding a special case to the API that won't
    > work for all situations anyways. I also don't see wrapper functions
    > as being all that hard.
    >

    Ok, after many semi-private discussions, how about this:

    1) New flag, BUS_DMA_INSWI, to signal that the caller is busdma_swi().
    2) Remove callback_mtx and replace it with callback2, a function
    pointer that wraps the callback with driver-dependent locking. This
    makes thing more flexible for alternate locking strategies.
    3) Move vm_swi to be INTR_MPSAFE. On every single arch, vm_swi
    only exists to call busdma_swi(). This should not preclude other
    tasks from being added to this SWI as long as appropriate locking
    is done.
    4) Have busdma_swi() check that callback2==NULL. If it does,
    grab Giant before calling bus_dmamap_load(). If it doesn't, call
    bus_dmamap_load() with callback2 instead of the original callback.
    5) bus_dmamap_load() checks BUS_DMA_INSWI==0 before overwriting
    the callback and callback_args fields of the map. It will blindly
    call 'callback' and rely on the caller (either the driver or
    busdma_swi) giving it the right pointer.

    Scott

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Justin T. Gibbs: "Re: API change for bus_dma"

    Relevant Pages

    • [PATCH 1/5] call i2c_probe from i2c core
      ... If you want to write a `sensors' driver, ... Whenever a new adapter is inserted, or for all adapters if the driver is ... the callback attach_adapteris called. ... -contains -1 for a probed detection, 0 for a forced detection, or a positive ...
      (Linux-Kernel)
    • Re: V4L2: switch to register_chrdev_region: needs testing/review of release() handling
      ... In addition it allows us to intercept the release callback when the ... drivers do the refcounting in varying degrees of competency (from 'not' ... closes as well will the release be called and the driver can do the ... reconnect the webcam even while some application is still using the old ...
      (Linux-Kernel)
    • Re: Cross Process Callbacks
      ... If you have the help of a wrapper API in the application space, ... application calls a function, CallMeBackWithData(Callback fcn, DWORD ... DeviceIoControl(driver, set up callback, event) ... Driver -> handles buffer cleanup and continues in device.exe context ...
      (microsoft.public.windowsce.platbuilder)
    • Re: Delay inside a worker thread
      ... Create invisible windows and use PostMessage to communicate between the threads ... >>hardware interupt which is signalled to your callback function in real ... >>by the device driver, you should simply have to call an API with an On Off ... >>the operation has completed with a callback. ...
      (microsoft.public.vc.mfc)
    • Re: V4L2: switch to register_chrdev_region: needs testing/review of release() handling
      ... Currently usb video drivers need to do the refcounting themselves, ... but with this patch they can rely on the release callback since it ... So on a disconnect the driver can call video_unregister_device ... reconnect the webcam even while some application is still using the ...
      (Linux-Kernel)