public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitri Belimov <d.belimov@gmail.com>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Stefan Ringel <stefan.ringel@arcor.de>,
	Bee Hock Goh <beehock@gmail.com>,
	Michael Krufky <mkrufky@kernellabs.com>
Subject: Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
Date: Thu, 7 Oct 2010 09:00:58 -0400	[thread overview]
Message-ID: <20101007090058.3fe0043a@glory.local> (raw)
In-Reply-To: <4CAC6E45.5030005@redhat.com>

Hi

> Em 06-10-2010 16:52, Dmitri Belimov escreveu:
> > Hi
> > 
> > Our TV card Behold X7 has two different RF input. This RF inputs
> > can switch between different RF sources. 
> > 
> > ANT 1 for analog and digital TV
> > ANT 2 for FM radio
> > 
> > The switch controlled by zl10353.
> > 
> > How to I can control this switch?
> > 
> > I found 2 way
> > 
> > 1. 
> > Use tuner callback to saa1734. add some params like
> > XC5000_TUNER_SET/XC5000_TUNER_SET_TV to the xc5000.h call tuner
> > callback from xc5000_set_analog_params with new params about
> > switching. In this case inside saa7134 need know about zl10353 and
> > configuration. I don't understand how to do. The structure
> > saa7134_dev hasn't pointer to the structure dvb_frontend. Or use
> > hardcoded i2c_addr and params.
> > 
> > 2.
> > Direct call switch the switcher from the tuner code. In this case
> > need know TV card type. I think it is not so good idea.
> 
> The issues between FM and TV mode is only a small part of a big
> problem that we're currently facing: drivers that support multiple
> types of streams, like radio, analog TV and digital TV need a way to
> avoid conflicts between different parts of the driver, and between a
> DVB and a V4L call.
> 
> The long-term solution seems to implement a tuner/frontend resource
> reservation routine. This will solve other problems as well, like
> having both analog and digital parts of the driver trying to access
> the same resource at the same time.
> 
> While implementing both analog and ISDB-T support for a saa7134-based
> board, I got one issue where analog tuner were trying to do RF
> callibration while the DVB demod were initialized. As the access to
> the demod requires one I2C gate setup and the access to the tuner
> requires another setup, both operations failed.
> 
> We had similar problems in em28xx and cx231xx. Both were partially
> solved with a lock, but still if the user tries to open both DVB and
> V4L interfaces, it will likely have problems.
> 
> So, we really need to implement some type of resource locking that
> will properly setup I2C gates, RF gates, etc, depending on the type
> of resource currently in use.
> 
> Basically, the idea would be to implement something like:
> 
> enum frontend_resource {
> 	ANALOG_TV_TUNER,
> 	DIGITAL_TV_TUNER,
> 	FM_TUNER,
> 	ANALOG_DEMOD,
> 	DIGITAL_DEMOD,
> };
> 
> And add a new callback at struct dvb_frontend_ops():
> 
> 	int (*set_resource)(struct dvb_frontend* fe, enum
> frontend_resource, bool reserve);
> 
> Those callbacks may replace i2c_gate_ctrl().
> 
> With those changes, when a driver needs to access, for example, a
> tuner at a dvb part of the driver, it would do:
> 
> fe->ops.set_resource(fe, DIGITAL_TV_TUNER, true);
> /* All i2c transactions and other operations needed at tuner */
> fe->ops.set_resource(fe, DIGITAL_TV_TUNER, false);
> 
> In other words, it will basically replace the current occurrences of
> i2c_gate_ctrl(), providing a clearer indication that the I2C change
> needed are to enable the access to the tuner.
> 
> The fun begins if other parts of the driver try to do different
> things on resources that may be shared. They can now say that they
> want to access the demod with:
> 
> fe->ops.set_resource(fe, DIGITAL_DEMOD, true);
> 
> So, demods operations will be protected by:
> 
> fe->ops.set_resource(fe, DIGITAL_DEMOD, true);
> 	/* All i2c transactions and other operations applied on demod
> */ fe->ops.set_resource(fe, DIGITAL_DEMOD, false);
> 
> It is up to driver callback to handle this call. If both
> DIGITAL_DEMOD and DIGITAL_TV_TUNER are at the same i2c bus (e.g.
> there's no i2c gate), and if there's no risk for one I2C access to
> affect the other, the callback can just return 0. Otherwise, it may
> return -EBUSY and let the caller wait for the resource to be freed
> with: wake_up(fe->ops.set_resource(fe, DIGITAL_DEMOD, true) == 0); or
> 	wake_up_interruptible(fe->ops.set_resource(fe, DIGITAL_DEMOD,
> true) == 0);
> 
> This way, when the resource is freed, the digital demod logic may
> happen.
> 
> Comments?

What about hardware encoders? May be need switch between some TV and encoders.
Switch input source, output bus and other.

With my best regards, Dmitry.

> Thanks,
> Mauro

  reply	other threads:[~2010-10-06 23:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18  7:30 [PATCH] xc5000, rework xc_write_reg Dmitri Belimov
2010-05-24  2:38 ` Devin Heitmueller
2010-05-25  1:49   ` Dmitri Belimov
2010-07-05 16:11     ` Mauro Carvalho Chehab
2010-07-05 19:07       ` Devin Heitmueller
2010-10-06 19:52         ` xc5000 and switch RF input Dmitri Belimov
2010-10-06 12:25           ` Mauro Carvalho Chehab
2010-10-06 12:40           ` [RFC] Resource reservation for frontend - Was: " Mauro Carvalho Chehab
2010-10-07 13:00             ` Dmitri Belimov [this message]
2010-10-07  0:28               ` Mauro Carvalho Chehab
2010-10-12 18:32                 ` Dmitri Belimov
2010-10-14  8:33             ` Antti Palosaari
2010-10-14  8:41               ` Devin Heitmueller
2010-10-15 15:33                 ` Antti Palosaari
2010-10-13 21:30         ` [PATCH] " Dmitri Belimov
2010-10-14  0:50           ` Devin Heitmueller
2010-10-14 16:12             ` Dmitri Belimov
2010-10-14 19:27               ` hermann pitton
2010-10-26  3:31         ` [PATCH] saa7134 behold A7 and H7 Dmitri Belimov

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=20101007090058.3fe0043a@glory.local \
    --to=d.belimov@gmail.com \
    --cc=beehock@gmail.com \
    --cc=dheitmueller@kernellabs.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=mkrufky@kernellabs.com \
    --cc=stefan.ringel@arcor.de \
    /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