Fwd: Removing Giant from a driver

[usleepless at gmail.com]

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