Message ID | 20170622200328.5387-1-d.scheller.oss@gmail.com (mailing list archive) |
---|---|
State | Changes Requested, archived |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <linux-media-owner@vger.kernel.org>) id 1dO8KH-0002GZ-JC; Thu, 22 Jun 2017 20:03:37 +0000 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.89/mailfrontend-8) with esmtp id 1dO8KE-0007wH-mG; Thu, 22 Jun 2017 22:03:37 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752145AbdFVUDd (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Thu, 22 Jun 2017 16:03:33 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:33530 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbdFVUDc (ORCPT <rfc822;linux-media@vger.kernel.org>); Thu, 22 Jun 2017 16:03:32 -0400 Received: by mail-wr0-f196.google.com with SMTP id x23so7254860wrb.0 for <linux-media@vger.kernel.org>; Thu, 22 Jun 2017 13:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=SPNVprNeqZwoDYgYFt4fK0bcmBBGaB9V8pZ+GFnfHPU=; b=LyX0PUVX+P+F7pSLYC/vQrI2u2iK1kHI3at64o5uq6v7sTvkfDgwJW407ADMePnqBR h4n908bteaMOBfApwgzbuhp4S1mihUByws0oQFLFW2MWpRAXWTkpHHFMrJL2f0ieYClI 3edjnnE21r+M2K2PmJWmi48nw1RTB1uyDsvJlBltS0nSAMZkDl+uO2/I4z3Dtwf6vOLS +EcLtQO/TgfnJLyeD3oPPDFODUZeMjsOvIKn0pMf/DwSQkYihrK0uSkzbGhQHay8q0oY zjegRXlsBMHmDZdAAWSyVCC6dedKhcbwj6YGia+BO+ACUoENaa4QqyFQQOiCSCRx7N0w 5mxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=SPNVprNeqZwoDYgYFt4fK0bcmBBGaB9V8pZ+GFnfHPU=; b=E/WI8Bb3SkT6uNr0C5de/IWd40So09LiJkcGtm+ydTrpyyrmssRE+O9XEMGWDOxXaP LsPh6LZpz63hwbX77xZel/JIsiNvIZy74RctmqB0FYA4pw2wySvTtbjdi9YXqYiK/RYv 4j5D6ldI7e+p1GdxfD2G3bNbxysgiK2immIzjq5frz6krKpKpPh19grke6ExMVHUio/Q 8TRqXx8CeJhQJ1HJoQZPpV4fBlycfmXdCUFzXEqLrm3dPy+79vNAOLyxmJ31XLV7h6Z8 yhJyFhgL99TmjkGswUxthIOzqmJ9pI+1RPPA4QQD8/dk/OOR7qcG+64OKzWAOvDgWHaM hgwA== X-Gm-Message-State: AKS2vOzlOPUHNUQzckH3nHxDl7hsSbnryWtY9xBzuZIw59j51rvZnTfD EPfdR5WoddDYXNqo X-Received: by 10.223.135.112 with SMTP id 45mr3069236wrz.133.1498161810722; Thu, 22 Jun 2017 13:03:30 -0700 (PDT) Received: from dvbdev.wuest.de (ip-37-24-178-151.hsi14.unitymediagroup.de. [37.24.178.151]) by smtp.gmail.com with ESMTPSA id c27sm2747187wrb.44.2017.06.22.13.03.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Jun 2017 13:03:30 -0700 (PDT) From: Daniel Scheller <d.scheller.oss@gmail.com> To: linux-media@vger.kernel.org, aospan@netup.ru, serjk@netup.ru Cc: mchehab@kernel.org Subject: [PATCH] [media] dvb-frontends/cxd2841er: require FE_HAS_SYNC for agc readout Date: Thu, 22 Jun 2017 22:03:28 +0200 Message-Id: <20170622200328.5387-1-d.scheller.oss@gmail.com> X-Mailer: git-send-email 2.13.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.6.22.195116 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' FORGED_FROM_GMAIL 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1700_1799 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DKIM_SIGNATURE 0, NO_URI_HTTPS 0, __ANY_URI 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_LIST_ID 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __YOUTUBE_RCVD 0' |
Commit Message
Daniel Scheller
June 22, 2017, 8:03 p.m. UTC
From: Daniel Scheller <d.scheller@gmx.net> When the demod driver puts the demod into sleep or shutdown state and it's status is then polled e.g. via "dvb-fe-tool -m", i2c errors are printed to the kernel log. If the last delsys was DVB-T/T2: cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1 cxd2841er: i2c rd failed=-5 addr=6c reg=26 and if it was DVB-C: cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1 cxd2841er: i2c rd failed=-5 addr=6c reg=49 This happens when read_status unconditionally calls into the read_signal_strength() function which triggers the read_agc_gain_*() functions, where these registered are polled. This isn't a critical thing since when the demod is active again, no more such errors are logged, however this might make users suspecting defects. Fix this by requiring fe_status FE_HAS_SYNC to be sure the demod is not put asleep or shut down. If FE_HAS_SYNC isn't set, additionally set the strength scale to NOT_AVAILABLE. Signed-off-by: Daniel Scheller <d.scheller@gmx.net> --- drivers/media/dvb-frontends/cxd2841er.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Comments
Em Thu, 22 Jun 2017 22:03:28 +0200 Daniel Scheller <d.scheller.oss@gmail.com> escreveu: > From: Daniel Scheller <d.scheller@gmx.net> > > When the demod driver puts the demod into sleep or shutdown state and it's > status is then polled e.g. via "dvb-fe-tool -m", i2c errors are printed > to the kernel log. If the last delsys was DVB-T/T2: > > cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1 > cxd2841er: i2c rd failed=-5 addr=6c reg=26 > > and if it was DVB-C: > > cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1 > cxd2841er: i2c rd failed=-5 addr=6c reg=49 > > This happens when read_status unconditionally calls into the > read_signal_strength() function which triggers the read_agc_gain_*() > functions, where these registered are polled. > > This isn't a critical thing since when the demod is active again, no more > such errors are logged, however this might make users suspecting defects. > > Fix this by requiring fe_status FE_HAS_SYNC to be sure the demod is not > put asleep or shut down. If FE_HAS_SYNC isn't set, additionally set the > strength scale to NOT_AVAILABLE. Requiring full lock for signal strength seems too much, as people usually rely on signal strength to adjust antenna. You should, instead, just check if the demod is shut down. Regards, Mauro > > Signed-off-by: Daniel Scheller <d.scheller@gmx.net> > --- > drivers/media/dvb-frontends/cxd2841er.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/dvb-frontends/cxd2841er.c b/drivers/media/dvb-frontends/cxd2841er.c > index 08f67d60a7d9..9fff031436f1 100644 > --- a/drivers/media/dvb-frontends/cxd2841er.c > +++ b/drivers/media/dvb-frontends/cxd2841er.c > @@ -3279,7 +3279,10 @@ static int cxd2841er_get_frontend(struct dvb_frontend *fe, > else if (priv->state == STATE_ACTIVE_TC) > cxd2841er_read_status_tc(fe, &status); > > - cxd2841er_read_signal_strength(fe); > + if (status & FE_HAS_SYNC) > + cxd2841er_read_signal_strength(fe); > + else > + p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE; > > if (status & FE_HAS_LOCK) { > cxd2841er_read_snr(fe); Thanks, Mauro
Hi, Yes, make sense. 2017-06-24 14:35 GMT-04:00 Mauro Carvalho Chehab <mchehab@s-opensource.com>: > Em Thu, 22 Jun 2017 22:03:28 +0200 > Daniel Scheller <d.scheller.oss@gmail.com> escreveu: > >> From: Daniel Scheller <d.scheller@gmx.net> >> >> When the demod driver puts the demod into sleep or shutdown state and it's >> status is then polled e.g. via "dvb-fe-tool -m", i2c errors are printed >> to the kernel log. If the last delsys was DVB-T/T2: >> >> cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1 >> cxd2841er: i2c rd failed=-5 addr=6c reg=26 >> >> and if it was DVB-C: >> >> cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1 >> cxd2841er: i2c rd failed=-5 addr=6c reg=49 >> >> This happens when read_status unconditionally calls into the >> read_signal_strength() function which triggers the read_agc_gain_*() >> functions, where these registered are polled. >> >> This isn't a critical thing since when the demod is active again, no more >> such errors are logged, however this might make users suspecting defects. >> >> Fix this by requiring fe_status FE_HAS_SYNC to be sure the demod is not >> put asleep or shut down. If FE_HAS_SYNC isn't set, additionally set the >> strength scale to NOT_AVAILABLE. > > Requiring full lock for signal strength seems too much, as people usually > rely on signal strength to adjust antenna. > > You should, instead, just check if the demod is shut down. > > Regards, > Mauro > >> >> Signed-off-by: Daniel Scheller <d.scheller@gmx.net> >> --- >> drivers/media/dvb-frontends/cxd2841er.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/media/dvb-frontends/cxd2841er.c b/drivers/media/dvb-frontends/cxd2841er.c >> index 08f67d60a7d9..9fff031436f1 100644 >> --- a/drivers/media/dvb-frontends/cxd2841er.c >> +++ b/drivers/media/dvb-frontends/cxd2841er.c >> @@ -3279,7 +3279,10 @@ static int cxd2841er_get_frontend(struct dvb_frontend *fe, >> else if (priv->state == STATE_ACTIVE_TC) >> cxd2841er_read_status_tc(fe, &status); >> >> - cxd2841er_read_signal_strength(fe); >> + if (status & FE_HAS_SYNC) >> + cxd2841er_read_signal_strength(fe); >> + else >> + p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE; >> >> if (status & FE_HAS_LOCK) { >> cxd2841er_read_snr(fe); > > > > Thanks, > Mauro
diff --git a/drivers/media/dvb-frontends/cxd2841er.c b/drivers/media/dvb-frontends/cxd2841er.c index 08f67d60a7d9..9fff031436f1 100644 --- a/drivers/media/dvb-frontends/cxd2841er.c +++ b/drivers/media/dvb-frontends/cxd2841er.c @@ -3279,7 +3279,10 @@ static int cxd2841er_get_frontend(struct dvb_frontend *fe, else if (priv->state == STATE_ACTIVE_TC) cxd2841er_read_status_tc(fe, &status); - cxd2841er_read_signal_strength(fe); + if (status & FE_HAS_SYNC) + cxd2841er_read_signal_strength(fe); + else + p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE; if (status & FE_HAS_LOCK) { cxd2841er_read_snr(fe);