Re: Fwd: Removing Giant from a driver



Dear John-Mark,

> what should it look like?

You should be creating a mutex (using mtx_init) at attach time, and
pass that mutex instead of Giant...

and don't touch busdma_lock_mutex? ( i am passing NULL, NULL at the moment )

> and how will i prevent the interrupt routine from interfering with
> userland operations? can i place a "mtx_lock()" call in the interrupt
> routine?

Correct.... Fast interrupt handlers cannot use a sleeping mutex, but
I doubt this driver is using a fast interrupt handler...

what is the benefit of a fast interrupt handler? ( i assume a
taskqueue is involved ). the interrupt-dma-code of this driver
includes tsleep-calls. does that hurt? i have a shared intterupt with
the second tuner-module and my soundcard.

i ask because the performance on my FBSD 6.x, P4 2.4ghz, 1 card, 2
tuners setup dissapoints me compared to my 4.11, P3 1.0ghz(!), 2
cards, 4 tuners setup.

the 4.11 machine is headless, the 6.x machine has 2 lcds through 1
ati-radeon. it is on the 6.x machine i try to run mythfrontend and use
the card at the same time.

i can imagine this is very complex: the 6.x machine is dealing with:
- capturing video ( using this driver )
- running mythfrontend ( driving XVideo and OSS )
- mythbackend reading from the cxm device, and writing to a NFS-share

this driver is generating about 1 megabyte per second. the 4.11
machine is handling 4 x 1 megabyte per second just fine writing it to
disk, and doing other stuff ( apache, postgresql, hylafax, firewall,
natd, nfs-server, mythbackends ).

> is there a howto somewhere?

There are man pages on how to use the various locking primitives, but
it is assumed that you have knowlege of concurrent programming...

i have, i know mutexes, semaphores, critical sections etc. heck, i
implemented 32-bits threading for watson-c on w3.11 once.

i have read http://www.freebsd.org/projects/busdma/
- this driver uses the busdma framework
- i have registered the interrupt INTR_MPSAFE
- SMPng locked: i have employed a mutex instead of spltty()
- p!=a safety: i don't think this is relevant right now

but i lack the connection with the freebsd-kernel. for example: i
don't understand what Giant is good for. i can imagine Giant is
important for a network-interface-driver because of the framework. but
what does the cxm driver has to do with it? is transforming this
driver to use fast-interrupts worthwhile? ( like the if-em driver )

You can take a look at books on pthreads and other related
matierals for info on using locks...

If you figure out the licensing issues w/ the firmware, I'll import
the driver into FreeBSD...

i suppose that will never happen:
- hauppauge firmware is needed
- i used GPLed linux/v4l2 headers and sourefiles to make the pvr150s/500s work


thank you for your time,

regards,

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



Relevant Pages

  • Re: [PATCH RFD] alternative kobject release wait mechanism
    ... The next idea is that a driver needs to synchronize its removemethod ... the suspend() method needs to block while readis running. ... First of all I think that I would merge pm and unbind mutex into one - ... thereby preventing autosuspend. ...
    (Linux-Kernel)
  • Re: Fwd: Removing Giant from a driver
    ... pass that mutex instead of Giant... ... I doubt this driver is using a fast interrupt handler... ... A fast interrupt handler doesn't context switch, ... don't understand what Giant is good for. ...
    (freebsd-hackers)
  • Re: iwlagn: associating with AP causes kernel hiccup
    ... there is no much system testing at all for what get's into merging ... This driver has been available and more-or-less working for ages. ... Haven't seen you've filled bug for it. ... I can write a patch to add a mutex and change it to: ...
    (Linux-Kernel)
  • RE: Mutex
    ... "mirage2k2" wrote: ... I normally wait on event objects - the signaled state is changed using ... I have also used fast mutex, they are easy you just call ... I try to use Mutex in my driver program and it does not work as i expect. ...
    (microsoft.public.development.device.drivers)
  • Re: Fwd: Removing Giant from a driver
    ... want to remove Giant from the code. ... You should be creating a mutex at attach time, ... I doubt this driver is using a fast interrupt handler... ...
    (freebsd-hackers)