All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.