[linux-dvb] Re: V4 API Implementation Q's

[Rob.McConnell@Zarlink.Com]

                      Michael Hunold                                                                                             
                      <hunold@convergen        To:       Rob.McConnell@Zarlink.Com                                               
                      ce.de>                   cc:       Johannes Stezenbach <js@convergence.de>, linux-dvb@linuxtv.org          
                                               Subject:  Re: [linux-dvb] Re: V4 API Implementation Q's                           
                      06-Apr-2004 04:29                                                                                          
                      PM                                                                                                         
                                                                                                                                 
                                                                                                                                 











Hi Michael,

Just a few more thoughts...

> > Would the "query capability" ioctl return a "snap-shot" of the actual
> > number of filters left of a certain type or would it return the max
number
> > of filters for each type?  I would prefer the former, as you could
easily
> > have the scenario that there are 32 PID filters in a demux device that
can
> > be allocated as a general purpose, section, or record filter.  Then if
you
> > allocated a section filter, for example, there would only be 31
> > filters/feeds left to _share_ between them all (instead of 32).  We
should
> > have a count in the driver for each filter/feed type that is kept
> > up-to-date.  So in the case where all filter types map down to a PID
> > filter/feed in the h/w, the count for each type would be adjusted
> > simultaneously (all decremented by one when allocating a filter).

> If you have a hardware that mixes all these kind of filters to one
> device, you'll have a hard time to calculate how many filters are
> actually available of each kind.

OK, from our discussions it sounds like it will be the responsibility of
the code "underneath" the API to control the resources.  We just specify
the max number of *h/w* filters of each type - right?  e.g. If you don't
have dedicated record h/w then you should set the
DVB_DMX_CAP_NUM_RECORDING_FILTERS to 0 - correct?

From what I can see, the AV7110 h/w automagically returns a handle to a new
feed with an error returned if no more resources are available, so the h/w
takes care of resources directly - right?  For other h/w that does not
behave like this (stuff I'm working on), you would require a conceptual
filter slot array where you may have 32 pid filter slots N audio decoder
slots and M video decoder slots.  You would then have to manage the
allocation/deallocation and setting up of filters from the set feed/filter
ioctl - is this correct?

> > In the later case, you could end up opening too many fd's and finding
out
> > that you couldn't set a filter/feed of the required type.  You would
then
> > have to close the fd and this then gets a little convoluted.  Wouldn't
it
> > be _cleaner_ to have an "open" on the specific filter/feed device which
> > would either succeed or not depending on the actual number of filters
left
> > (you could still use the count method as above).  Then you could issue
the
> > necessary ioctl to setup the filter/feed specification.  In fact, the
> > actual IOCTLs ordinal numbers could be kept the same between devices:

> You'll always have race conditions. If you query for the number of
> available pidfilters and the number is 1, there can always be another
> data-harvesting application in the background that can get this last
> pidfilter and there is nothing you can do about it.

What about the V3 API, that allocates a filter slot (with locking) that can
later be used by the SET ioctl?

> IMHO this stuff isn't critical, ie. you don't need to have atomic
> open_and_set() function, this is simply too heavy.

Is it? We seem to do this anyway in the V3 API.

> Setting a pidfilter can always fail (if you specified invalid
> parameters), so you'll have to check the return code of the SETFILTER
> ioctls anyway. EBUSY (in case there are no filters available) is just
> another error code you need to check.

True, so you are cutting down on the check for any error at open time.


Ok, another Q is regards to how the record filter adding/deletion mechanism
works.  I asked this Q b4 in a previous email, but didn't get a reply
(sorry if you haven't had a chance to comment).  The Q went on the lines of
does the add pid ioctl for the record filter actually go and try to
allocate a pid filter if one isn't already running (effectively implement
the DVB_DMX_SET_PID_FILTER ioctl)?

Also, for h/w that doesn't have dedicated record h/w, would the output of
each pid filter be directed to a common ringbuffer with a single copy or
would you have a 2 copy approach - one from the h/w buffer to a kernel
buffer and the 2nd from the kernel buffer to the common ringbuffer?  I
would guess the later, as you may want to setup some normal pid filters
first and then decide to setup a record in parallel as well.

The record filter is a bit of pain in terms of nomenclature and
implementation.  I know 2 types of h/w that operate in 2 different ways.
One is a register that has a bit position for each pid filter slot that you
want to record and the data is dumped in a *common* area of memory.  This
assumes that you have already setup actual pid filters in the h/w first and
there is a dedicated record filter "slot".  The "slot" here is really just
the common ringbuffer in memory, as no pid filter(s) is/are actually "tied"
to this buffer.  The other h/w I know has actual pid filters that all
connect up to a common area of memory.  In this case, you again need to
setup each pid filter that you want to record, but there are multiple
record filter "slots".  So what do we now class as a "feed" - a filter or
buffer or both the filter and buffer connected together?  Does the V4 API
handle all these record implementations without any fuss?

Finally, what are the meaning of the newly added record methods in the
filter bank:

try_add_recording_pid
commit_recording_pid
confirm_recording_data
etc.

TIA,

Rob : )





-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.