linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: Brad Love <brad@nextdimension.cc>, linux-media@vger.kernel.org
Subject: Re: [PATCH v3 05/14] si2157: Briefly wait for tuning operation to complete
Date: Fri, 15 Nov 2019 13:31:35 +0200	[thread overview]
Message-ID: <7cfd7b07-c3d6-a40f-d2c1-b3ee1bea10ec@iki.fi> (raw)
In-Reply-To: <20191114200408.28883-6-brad@nextdimension.cc>

On 11/14/19 10:03 PM, Brad Love wrote:
> To detect errors in the tuning operation, this waits up 40ms for operation
> completion status. This allows for error detection and prevents issuing
> additional commands to the tuner before it is finished.
> 
> Tuning typically completes in 20-30ms.

So that adds some magic waiting at the end of both digital and analog 
tuning.

For digital side it surely is not needed, it has been ages without. 
Tuning on digital side works almost always on 3 phases, 1) program 
tuner, 2) program demod, 3) start waiting demod lock. Tuner is generally 
ready much faster than demod, it is usually just programming PLL and PLL 
locks very fast if it is inside supported frequency ranges and outside 
ranges it does not lock at all. Some tuners supports PLL lock reading, 
but generally there is no idea to read it on normal operation. So 
all-in-all, tuner is almost certainly first device which is ready on 
that chain and if something fails dvb-frontend does retuning.

For analog stuff you added I am not very familiar. Maybe you should 
check analog demod status somehow, is there such callback to read status 
as digital side is..?

Antti

> 
> Signed-off-by: Brad Love <brad@nextdimension.cc>
> ---
> Since v2:
> - Split into two patches, tune completion and signal lock
> 
>   drivers/media/tuners/si2157.c | 52 +++++++++++++++++++++++++++++++++++
>   1 file changed, 52 insertions(+)
> 
> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
> index 78a855df30da..cac4870017f5 100644
> --- a/drivers/media/tuners/si2157.c
> +++ b/drivers/media/tuners/si2157.c
> @@ -301,6 +301,54 @@ static int si2157_sleep(struct dvb_frontend *fe)
>   	return ret;
>   }
>   
> +static int si2157_tune_wait(struct i2c_client *client)
> +{
> +#define TUN_TIMEOUT 40
> +	struct si2157_dev *dev = i2c_get_clientdata(client);
> +	int ret;
> +	unsigned long timeout;
> +	unsigned long start_time;
> +	u8 wait_status;
> +
> +	mutex_lock(&dev->i2c_mutex);
> +
> +	/* wait tuner command complete */
> +	start_time = jiffies;
> +	timeout = start_time + msecs_to_jiffies(TUN_TIMEOUT);
> +	while (!time_after(jiffies, timeout)) {
> +		ret = i2c_master_recv(client, &wait_status,
> +				      sizeof(wait_status));
> +		if (ret < 0) {
> +			goto err_mutex_unlock;
> +		} else if (ret != sizeof(wait_status)) {
> +			ret = -EREMOTEIO;
> +			goto err_mutex_unlock;
> +		}
> +
> +		/* tuner done? */
> +		if ((wait_status & 0x81) == 0x81)
> +			break;
> +		usleep_range(5000, 10000);
> +	}
> +
> +	dev_dbg(&client->dev, "tuning took %d ms, status=0x%x\n",
> +		jiffies_to_msecs(jiffies) - jiffies_to_msecs(start_time),
> +		wait_status);
> +
> +	if ((wait_status & 0xc0) != 0x80) {
> +		ret = -ETIMEDOUT;
> +		goto err_mutex_unlock;
> +	}
> +
> +	mutex_unlock(&dev->i2c_mutex);
> +	return 0;
> +
> +err_mutex_unlock:
> +	mutex_unlock(&dev->i2c_mutex);
> +	dev_err(&client->dev, "failed=%d\n", ret);
> +	return ret;
> +}
> +
>   static int si2157_set_params(struct dvb_frontend *fe)
>   {
>   	struct i2c_client *client = fe->tuner_priv;
> @@ -400,6 +448,8 @@ static int si2157_set_params(struct dvb_frontend *fe)
>   	dev->bandwidth = bandwidth;
>   	dev->frequency = c->frequency;
>   
> +	si2157_tune_wait(client); /* wait to complete, ignore any errors */
> +
>   	return 0;
>   err:
>   	dev->bandwidth = 0;
> @@ -594,6 +644,8 @@ static int si2157_set_analog_params(struct dvb_frontend *fe,
>   
>   	dev->bandwidth = bandwidth;
>   
> +	si2157_tune_wait(client); /* wait to complete, ignore any errors */
> +
>   	return 0;
>   err:
>   	dev->bandwidth = 0;
> 

-- 
http://palosaari.fi/

  reply	other threads:[~2019-11-15 11:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14 20:03 [PATCH v3 00/14] si2157: Analog tuning and optimizations Brad Love
2019-11-14 20:03 ` [PATCH v3 01/14] si2157: Enable tuner status flags Brad Love
2019-11-14 20:03 ` [PATCH v3 02/14] si2157: Check error status bit on cmd execute Brad Love
2019-11-15 11:09   ` Antti Palosaari
2019-11-14 20:03 ` [PATCH v3 03/14] si2157: Better check for running tuner in init Brad Love
2019-11-15 11:16   ` Antti Palosaari
2019-11-14 20:03 ` [PATCH v3 04/14] si2157: Add analog tuning related functions Brad Love
2019-11-24  5:09   ` Antti Palosaari
2019-12-19 13:13     ` Mauro Carvalho Chehab
2019-12-20 15:32       ` Antti Palosaari
2020-02-01 21:20       ` Brad Love
2019-11-14 20:03 ` [PATCH v3 05/14] si2157: Briefly wait for tuning operation to complete Brad Love
2019-11-15 11:31   ` Antti Palosaari [this message]
2019-11-14 20:04 ` [PATCH v3 06/14] si2157: module debug option to wait on signal lock Brad Love
2019-11-14 20:04 ` [PATCH v3 07/14] cx23885: Add analog frontend to Hauppauge QuadHD Brad Love
2019-11-14 20:04 ` [PATCH v3 08/14] cx23885: Add analog frontend to 1265_K4 Brad Love
2019-11-14 20:04 ` [PATCH v3 09/14] cx23885: Add analog frontend to HVR5525 Brad Love
2019-11-14 20:04 ` [PATCH v3 10/14] cx23885: Add i2c device analog tuner support Brad Love
2019-11-14 20:04 ` [PATCH v3 11/14] cx231xx: " Brad Love
2019-11-14 20:04 ` [PATCH v3 12/14] si2157: add on-demand rf strength func Brad Love
2019-11-15 20:23   ` Antti Palosaari
2019-11-14 20:04 ` [PATCH v3 13/14] lgdt3306a: Add CNR v5 stat Brad Love
2019-11-14 20:04 ` [PATCH v3 14/14] cx25840: Register labeling, chip specific correction Brad Love

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=7cfd7b07-c3d6-a40f-d2c1-b3ee1bea10ec@iki.fi \
    --to=crope@iki.fi \
    --cc=brad@nextdimension.cc \
    --cc=linux-media@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).