From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Marc Gonzalez <marc.w.gonzalez@free.fr>
Cc: linux-media <linux-media@vger.kernel.org>,
Brad Love <brad@nextdimension.cc>, Sean Young <sean@mess.org>,
Arnd Bergmann <arnd@arndb.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 4/4] media: dvb_frontend: disable zigzag mode if not possible
Date: Mon, 22 Mar 2021 16:33:29 +0100 [thread overview]
Message-ID: <20210322163329.4afe27ed@coco.lan> (raw)
In-Reply-To: <20bb2501-8307-185e-ebec-a83488353a0b@free.fr>
Em Thu, 18 Jun 2020 11:50:54 +0200
Marc Gonzalez <marc.w.gonzalez@free.fr> escreveu:
> On 17/06/2020 20:52, Mauro Carvalho Chehab wrote:
>
> > For the zigzag to work, the core needs to have a frequency
> > shift. Without that, the zigzag code will just try re-tuning
> > several times at the very same frequency, with seems wrong.
>
> s/with/which
>
> Suggest: "the core requires a frequency shift value"
>
> > So, add a warning when this happens, and fall back to the
> > single-shot mode.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> > drivers/media/dvb-core/dvb_frontend.c | 141 +++++++++++++++-----------
> > 1 file changed, 79 insertions(+), 62 deletions(-)
>
> It's hard to discern in the diff what is just white-space adjustment
> from one less tab, and what is new code that requires more scrutiny.
> I'll try applying the patch, and then diff -w.
> Yes, that's much better.
>
> > diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
> > index ed85dc2a9183..cb577924121e 100644
> > --- a/drivers/media/dvb-core/dvb_frontend.c
> > +++ b/drivers/media/dvb-core/dvb_frontend.c
> > @@ -642,6 +642,9 @@ static void dvb_frontend_wakeup(struct dvb_frontend *fe)
> > wake_up_interruptible(&fepriv->wait_queue);
> > }
> >
> > +static u32 dvb_frontend_get_stepsize(struct dvb_frontend *fe);
> > +static void prepare_tuning_algo_parameters(struct dvb_frontend *fe);
> > +
> > static int dvb_frontend_thread(void *data)
> > {
> > struct dvb_frontend *fe = data;
> > @@ -696,78 +699,92 @@ static int dvb_frontend_thread(void *data)
> > fepriv->reinitialise = 0;
> > }
> >
> > - /* do an iteration of the tuning loop */
> > - if (fe->ops.get_frontend_algo) {
> > + if (fe->ops.get_frontend_algo)
> > algo = fe->ops.get_frontend_algo(fe);
> > - switch (algo) {
> > - case DVBFE_ALGO_HW:
> > - dev_dbg(fe->dvb->device, "%s: Frontend ALGO = DVBFE_ALGO_HW\n", __func__);
> > + else
> > + algo = DVBFE_ALGO_SW;
> >
> > - if (fepriv->state & FESTATE_RETUNE) {
> > - dev_dbg(fe->dvb->device, "%s: Retune requested, FESTATE_RETUNE\n", __func__);
> > - re_tune = true;
> > - fepriv->state = FESTATE_TUNED;
> > - } else {
> > - re_tune = false;
> > - }
> > + /* do an iteration of the tuning loop */
> > + switch (algo) {
> > + case DVBFE_ALGO_SW:
> > + prepare_tuning_algo_parameters(fe);
> >
> > - if (fe->ops.tune)
> > - fe->ops.tune(fe, re_tune, fepriv->tune_mode_flags, &fepriv->delay, &s);
> > -
> > - if (s != fepriv->status && !(fepriv->tune_mode_flags & FE_TUNE_MODE_ONESHOT)) {
> > - dev_dbg(fe->dvb->device, "%s: state changed, adding current state\n", __func__);
> > - dvb_frontend_add_event(fe, s);
> > - fepriv->status = s;
> > - }
> > - break;
> > - case DVBFE_ALGO_SW:
> > + if (fepriv->max_drift) {
> > dev_dbg(fe->dvb->device, "%s: Frontend ALGO = DVBFE_ALGO_SW\n", __func__);
> > dvb_frontend_swzigzag(fe);
> > break;
> > - case DVBFE_ALGO_CUSTOM:
> > - dev_dbg(fe->dvb->device, "%s: Frontend ALGO = DVBFE_ALGO_CUSTOM, state=%d\n", __func__, fepriv->state);
> > - if (fepriv->state & FESTATE_RETUNE) {
> > - dev_dbg(fe->dvb->device, "%s: Retune requested, FESTAT_RETUNE\n", __func__);
> > - fepriv->state = FESTATE_TUNED;
> > + }
> > +
> > + /*
> > + * See prepare_tuning_algo_parameters():
> > + * - Some standards may not use zigzag.
> > + */
> > + if (!dvb_frontend_get_stepsize(fe))
> > + dev_warn(fe->dvb->device,
> > + "disabling sigzag, as frontend doesn't set frequency step size\n");
>
> s/sigzag/zigzag
>
> I don't understand why you're calling dvb_frontend_get_stepsize() again?
> prepare_tuning_algo_parameters() already tried its best to set fepriv->step_size
>
> Why not just:
>
> if (fepriv->max_drift)
> do the zigzag
> else
> warn that zigzag is disabled
>
> > +
> > + /* fall through */
>
> Why would you want to fall through from DVBFE_ALGO_SW to DVBFE_ALGO_HW?
> I think this changes the behavior before the patch.
I double-checked this patch. What happens is that there are 3
types of DVB devices:
1. Devices where the Zigzag happens at the hardware level,
automatically (DVBFE_ALGO_HW). All they need is to call
fe->ops.tune() logic once;
2. Devices that have their own hardware-assisted zigzag logic.
Those are handled via DVBFE_ALGO_CUSTOM logic. Those use
an special callback: fe->ops.search(fe).
3. Devices that require the Kernel to do zigzag (DVBFE_ALGO_SW).
Those should set max_drift and other fields, in order to
setup the zigzag steps.
In other words, a device driver which uses DVBFE_ALGO_SW should
provide the vars that are needed for the zigzag to work, as
otherwise, the software zigzag would be just wasting time, as
it won't be different than a device driver using DVBFE_ALGO_HW.
What the above patch does is to generate a warning when
DVBFE_ALGO_SW is used without setting the frequency shift,
which is an uAPI/kAPI violation. On such cases, it will fallback
to DVBFE_ALGO_HW.
The main issue is that testing this patch is not trivial.
As you pointed, it can cause regressions. So, instead of this
patch, I'll merge one that will just print a warning. We need
to fix the frontend drivers case by case.
Thanks,
Mauro
next prev parent reply other threads:[~2021-03-22 15:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 18:52 [RFC 0/4] Don't do tuning zigzag using the very same frequency Mauro Carvalho Chehab
2020-06-17 18:52 ` [RFC 1/4] media: atomisp: fix identation at I2C Kconfig menu Mauro Carvalho Chehab
2020-06-17 18:52 ` [RFC 2/4] media: atomisp: fix help message for ISP2401 selection Mauro Carvalho Chehab
2020-06-17 18:52 ` [RFC 3/4] media: dvb_frontend: move algo-specific settings to a function Mauro Carvalho Chehab
2020-06-18 9:20 ` Marc Gonzalez
2020-06-17 18:52 ` [RFC 4/4] media: dvb_frontend: disable zigzag mode if not possible Mauro Carvalho Chehab
2020-06-18 9:50 ` Marc Gonzalez
2021-03-22 15:33 ` Mauro Carvalho Chehab [this message]
2021-03-22 15:33 ` [PATCH] media: dvb_frontend: warn if frontend driver has API issues Mauro Carvalho Chehab
2020-06-17 19:07 ` [RFC 0/4] Don't do tuning zigzag using the very same frequency Mauro Carvalho Chehab
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=20210322163329.4afe27ed@coco.lan \
--to=mchehab+huawei@kernel.org \
--cc=arnd@arndb.de \
--cc=brad@nextdimension.cc \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=marc.w.gonzalez@free.fr \
--cc=sean@mess.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 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.