public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Michael Krufky <mkrufky@kernellabs.com>,
	LMML <linux-media@vger.kernel.org>
Subject: Re: Details about DVB frontend API
Date: Mon, 07 Dec 2009 19:23:57 -0200	[thread overview]
Message-ID: <4B1D726D.3010409@redhat.com> (raw)
In-Reply-To: <4B1D6CFA.2020602@infradead.org>

Mauro Carvalho Chehab wrote:
> Michael Krufky wrote:
>> On Fri, Dec 4, 2009 at 3:02 PM, VDR User <user.vdr@gmail.com> wrote:
>>> No activity in this thread for 2 weeks now.  Has there been any progress?
> 
>> I have stated that I like Manu's proposal, but I would prefer that the
>> get_property (s2api) interface were used, because it totally provides
>> an interface that is sufficient for this feature.
> 
> I've ported Manu's proposal to S2API way of handling it. It is just compiled
> only. I haven't test it yet on a real driver.
> 
> Comments?
> 
> ---
> 
> Add support for frontend statistics via S2API
> 
> The current DVB V3 API to handle statistics has two issues:
> 	- Retrieving several values can't be done atomically;
> 	- There's no indication about scale information.
> 
> This patch solves those two issues by adding a group of S2API
> that handles the needed statistics operations. It basically ports the
> proposal of Manu Abraham <abraham.manu@gmail.com> To S2API.
> 
> As the original patch, both of the above issues were addressed.
> 
> In order to demonstrate the changes on an existing driver for the new API, I've
> implemented it at the cx24123 driver.
> 
> There are some advantages of using this approach over using the static structs
> of the original proposal:
> 	- userspace can select an arbitrary number of parameters on his get request;
> 	- the latency to retrieve just one parameter is lower than retrieving
> several parameters. On the cx24123 example, if user wants just signal strength,
> the latency is the same as reading one register via i2c bus. If using the original
> proposal, the latency would be 6 times worse, since you would need to get 3 properties
> at the same time;
> 	- the latency for reading all 3 parameters at the same time is equal to
> the latency of the original proposal;
> 	- if newer statistics parameters will be needed in the future, it is just
> a matter of adding additional S2API command/value pairs;
> 	- the DVB V3 calls can be easily implemented as a call to the new get_stats ops,
> without adding extra latency time.

In time:

I only wrote the get callback. It could be interesting to implement also the set callback
for the DTV_FE*_UNIT parameters if there are some cases where the same driver can provide
a different set of units/parameters. This way, it is possible for userspace to
negotiate what parameter type he wants, on such drivers.
> 
> Thanks to Manu Abraham <abraham.manu@gmail.com> for his initial proposal.
> 

Cheers,
Mauro.

  reply	other threads:[~2009-12-07 21:23 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-22 19:13 Details about DVB frontend API Jean Delvare
2009-10-22 19:27 ` Devin Heitmueller
2009-10-22 19:38   ` VDR User
2009-10-23 12:47   ` Jean Delvare
2009-10-22 20:10 ` Mauro Carvalho Chehab
2009-10-22 20:29   ` Manu Abraham
2009-10-23  0:12     ` Markus Rechberger
2009-10-23  1:00       ` Manu Abraham
2009-10-23 19:02     ` VDR User
2009-10-23 23:34       ` Markus Rechberger
2009-11-17 19:46     ` Mauro Carvalho Chehab
2009-11-17 19:55       ` Devin Heitmueller
2009-11-17 21:48         ` Jean Delvare
2009-11-17 22:53         ` Mauro Carvalho Chehab
2009-11-18  9:32           ` Devin Heitmueller
2009-11-18 14:04             ` Mauro Carvalho Chehab
2009-11-18 15:17               ` Devin Heitmueller
2009-11-18 15:35                 ` Michael Krufky
2009-11-18 15:35               ` Devin Heitmueller
2009-11-20  9:29       ` Manu Abraham
2009-11-20 11:37         ` Julian Scheel
2009-11-20 16:08           ` Manu Abraham
2009-11-20 23:40             ` Julian Scheel
2009-12-04 20:02               ` VDR User
2009-12-04 20:59                 ` Michael Krufky
2009-12-05 17:30                   ` Mauro Carvalho Chehab
2009-12-05 17:42                     ` Michael Krufky
2009-12-05 19:29                       ` Mauro Carvalho Chehab
2009-12-07 21:00                   ` Mauro Carvalho Chehab
2009-12-07 21:23                     ` Mauro Carvalho Chehab [this message]
2009-10-23 12:53   ` Jean Delvare
2009-10-23  5:11 ` Mike Booth
2009-10-23 15:47 ` Jean Delvare
2009-10-23 16:45   ` Michael Krufky
2009-10-24 16:31 ` David T. L. Wong
  -- strict thread matches above, loose matches on Subject: below --
2009-10-22 22:18 Hans Verkuil
2009-10-23  2:17 ` Steven Toth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B1D726D.3010409@redhat.com \
    --to=mchehab@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mkrufky@kernellabs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox