From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: "Daniel W. S. Almeida" <dwlsalmeida@gmail.com>
Cc: kstewart@linuxfoundation.org, linux-kernel@vger.kernel.org,
rfontana@redhat.com, tglx@linutronix.de,
linux-kernel-mentees@lists.linuxfoundation.org,
linux-media@vger.kernel.org
Subject: Re: [Linux-kernel-mentees] [PATCH] media: dvb_dummy_fe.c: add members to dvb_dummy_fe_state
Date: Mon, 2 Dec 2019 06:50:47 +0100 [thread overview]
Message-ID: <20191202065047.3cffda7a@kernel.org> (raw)
In-Reply-To: <13629649-f363-4787-e88b-784f8309bfcd@gmail.com>
Em Mon, 2 Dec 2019 01:49:38 -0300
"Daniel W. S. Almeida" <dwlsalmeida@gmail.com> escreveu:
> Hi Mauro, thanks for checking out my work!
>
> > please don't add fields at the
> > struct while they're not used, as this makes harder for reviewers to be
> > sure that we're not adding bloatware at the code.
>
> OK.
>
> > Please remember that
> > we want one logical change per patch.
> >
> > It means that, if you add a state->frontend_status at the driver, the
> > patch should implement the entire logic for it.
> I will keep this in mind.
>
> > static int dvb_dummy_fe_sleep(struct dvb_frontend* fe)
> > {
> > +
> > + struct dvb_dummy_fe_state *state = fe->demodulator_priv;
> > +
> > + state->sleeping = true;
> > +
>
> > Hmm...what's the sense of adding it? Where are you setting it to false?
> > Where are you using the sleeping state?
>
> I noted some drivers seem to instruct the hardware into a low power state. Take helene, for instance:
>
> static int helene_sleep(struct dvb_frontend *fe)
> {
> struct helene_priv *priv = fe->tuner_priv;
>
> dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
> helene_enter_power_save(priv);
> return 0;
> }
>
> static int helene_enter_power_save(struct helene_priv *priv)
> {
> dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
> if (priv->state == STATE_SLEEP)
> return 0;
>
> /* Standby setting for CPU */
> helene_write_reg(priv, 0x88, 0x0);
>
> /* Standby setting for internal logic block */
> helene_write_reg(priv, 0x87, 0xC0);
>
> priv->state = STATE_SLEEP;
> return 0;
> }
>
> As we are emulating some piece of hardware I thought it would be enough to add a simple bool to indicate that the device was sleeping.
Yeah, that could have some value. Yet, if you're doing that, I suggest
to add a function to change the device power state, as this is what a
real driver would do. Something similar to:
static inline void change_power_state(struct state *st, bool on)
{
/* A real driver would have commands here to wake/sleep the dev */
st->power = on;
}
In any case, a real device on sleeping mode will not be tuning any
channels, so all stats will reflect that, e. g:
- frontend status will return 0;
- stats that depends on having a lock will be set with:
FE_SCALE_NOT_AVAILABLE
tip: most stats are like that
- stats like signal strength should probably return 0.
Not so sure what SNR will return, but probably it should return
FE_SCALE_NOT_AVAILABLE too, as this is usually calculated indirectly
once the device is locked.
On other words, only signal strength and stats should return a value
with would be 0 on both cases. All other stats should return
FE_SCALE_NOT_AVAILABLE.
Btw, as this depends on having the stats implemented, I would suggest you to
first finish the tuning and stats part of the driver. Only after having those
patches, apply the power mode patch.
>
> This patch was a bit convoluted on my part. Let's iron out the issues you pointed out in v2.
>
> - Daniel.
Cheers,
Mauro
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: "Daniel W. S. Almeida" <dwlsalmeida@gmail.com>
Cc: gregkh@linuxfoundation.org, rfontana@redhat.com,
kstewart@linuxfoundation.org, tglx@linutronix.de,
skhan@linuxfoundation.org,
linux-kernel-mentees@lists.linuxfoundation.org,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: dvb_dummy_fe.c: add members to dvb_dummy_fe_state
Date: Mon, 2 Dec 2019 06:50:47 +0100 [thread overview]
Message-ID: <20191202065047.3cffda7a@kernel.org> (raw)
In-Reply-To: <13629649-f363-4787-e88b-784f8309bfcd@gmail.com>
Em Mon, 2 Dec 2019 01:49:38 -0300
"Daniel W. S. Almeida" <dwlsalmeida@gmail.com> escreveu:
> Hi Mauro, thanks for checking out my work!
>
> > please don't add fields at the
> > struct while they're not used, as this makes harder for reviewers to be
> > sure that we're not adding bloatware at the code.
>
> OK.
>
> > Please remember that
> > we want one logical change per patch.
> >
> > It means that, if you add a state->frontend_status at the driver, the
> > patch should implement the entire logic for it.
> I will keep this in mind.
>
> > static int dvb_dummy_fe_sleep(struct dvb_frontend* fe)
> > {
> > +
> > + struct dvb_dummy_fe_state *state = fe->demodulator_priv;
> > +
> > + state->sleeping = true;
> > +
>
> > Hmm...what's the sense of adding it? Where are you setting it to false?
> > Where are you using the sleeping state?
>
> I noted some drivers seem to instruct the hardware into a low power state. Take helene, for instance:
>
> static int helene_sleep(struct dvb_frontend *fe)
> {
> struct helene_priv *priv = fe->tuner_priv;
>
> dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
> helene_enter_power_save(priv);
> return 0;
> }
>
> static int helene_enter_power_save(struct helene_priv *priv)
> {
> dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
> if (priv->state == STATE_SLEEP)
> return 0;
>
> /* Standby setting for CPU */
> helene_write_reg(priv, 0x88, 0x0);
>
> /* Standby setting for internal logic block */
> helene_write_reg(priv, 0x87, 0xC0);
>
> priv->state = STATE_SLEEP;
> return 0;
> }
>
> As we are emulating some piece of hardware I thought it would be enough to add a simple bool to indicate that the device was sleeping.
Yeah, that could have some value. Yet, if you're doing that, I suggest
to add a function to change the device power state, as this is what a
real driver would do. Something similar to:
static inline void change_power_state(struct state *st, bool on)
{
/* A real driver would have commands here to wake/sleep the dev */
st->power = on;
}
In any case, a real device on sleeping mode will not be tuning any
channels, so all stats will reflect that, e. g:
- frontend status will return 0;
- stats that depends on having a lock will be set with:
FE_SCALE_NOT_AVAILABLE
tip: most stats are like that
- stats like signal strength should probably return 0.
Not so sure what SNR will return, but probably it should return
FE_SCALE_NOT_AVAILABLE too, as this is usually calculated indirectly
once the device is locked.
On other words, only signal strength and stats should return a value
with would be 0 on both cases. All other stats should return
FE_SCALE_NOT_AVAILABLE.
Btw, as this depends on having the stats implemented, I would suggest you to
first finish the tuning and stats part of the driver. Only after having those
patches, apply the power mode patch.
>
> This patch was a bit convoluted on my part. Let's iron out the issues you pointed out in v2.
>
> - Daniel.
Cheers,
Mauro
next prev parent reply other threads:[~2019-12-02 5:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-30 4:54 [Linux-kernel-mentees] [PATCH] media: dvb_dummy_fe.c: add members to dvb_dummy_fe_state Daniel W. S. Almeida
2019-11-30 4:54 ` Daniel W. S. Almeida
2019-12-01 8:07 ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2019-12-01 8:07 ` Mauro Carvalho Chehab
2019-12-02 4:49 ` [Linux-kernel-mentees] " Daniel W. S. Almeida
2019-12-02 5:50 ` Mauro Carvalho Chehab [this message]
2019-12-02 5:50 ` 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=20191202065047.3cffda7a@kernel.org \
--to=mchehab@kernel.org \
--cc=dwlsalmeida@gmail.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=rfontana@redhat.com \
--cc=tglx@linutronix.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 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.