From: William Breathitt Gray <william.gray@linaro.org>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Chris Paterson <Chris.Paterson2@renesas.com>,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v9 4/5] counter: Add Renesas RZ/G2L MTU3a counter driver
Date: Fri, 16 Dec 2022 12:34:53 -0500 [thread overview]
Message-ID: <Y5ysPT3wrc7h9x2T@fedora> (raw)
In-Reply-To: <OS0PR01MB5922D9A52A0A6D01B73503D686E69@OS0PR01MB5922.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]
On Fri, Dec 16, 2022 at 05:24:02PM +0000, Biju Das wrote:
> Hi William Breathitt Gray,
>
> > Subject: Re: [PATCH v9 4/5] counter: Add Renesas RZ/G2L MTU3a counter driver
> >
> > On Fri, Dec 16, 2022 at 05:00:30PM +0000, Biju Das wrote:
> > > > Hello Biju,
> > > >
> > > > Do you need to take the ch->lock before checking ch->is_busy to
> > > > ensure it does not change?
> > >
> > > priv->count_is_enabled[count->id]-> true means channel is held by counter.
> > > So pwm won't be able to change the state ch->is_busy.
> > >
> > > priv->count_is_enabled[count->id]-> false and if there is contention
> > > priv->for ch->busy
> > > whoever is first calling rz_mtu3_request_channel() will get the channel.
> > > among pwm_request and counter_enable.
> > >
> > > So I think it is safe here. Please correct me if I am missing something.
> > >
> > > static inline bool rz_mtu3_request_channel(struct rz_mtu3_channel *ch)
> > > {
> > > bool is_idle;
> > >
> > > mutex_lock(&ch->lock);
> > > is_idle = !ch->is_busy;
> > > if (is_idle)
> > > ch->is_busy = true;
> > > mutex_unlock(&ch->lock);
> > >
> > > return is_idle;
> > > }
> >
> > Okay seems safe then. If the respective count_is_enabled will only be true
> > when the respective channel is held by the counter, is there a need to check
> > ch->is_busy, or would checking count_is_enabled alone suffice?
>
> We still can configure below properties before enabling the count.
> That can be done only when ch->is_busy = false or ch->is_busy= true and count_is_enabled.
> That is channel is used by the counter.
>
> /sys/bus/counter/devices/counterX/external_input_phase_clock_select
> /sys/bus/counter/devices/counterX/long_word_access_ctrl_mode
> /sys/bus/counter/devices/counterX/count2/count
> /sys/bus/counter/devices/counterX/count2/ceiling
>
> Cheers,
> Biju
I see what you mean now, we'll need to check ch->is_busy regardless and
not just the count_is_enable state. That should be fine then, thanks for
explaining.
William Breathitt Gray
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-12-16 17:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 10:31 [PATCH v9 0/5] Add RZ/G2L MTU3a Core, Counter and pwm driver Biju Das
2022-12-14 10:31 ` [PATCH v9 1/5] dt-bindings: timer: Document RZ/G2L MTU3a bindings Biju Das
2022-12-14 10:31 ` [PATCH v9 2/5] clocksource/drivers: Add Renesas RZ/G2L MTU3a core driver Biju Das
2022-12-14 10:31 ` [PATCH v9 3/5] Documentation: ABI: sysfs-bus-counter: add cascade_counts_enable and external_input_phase_clock_select Biju Das
2022-12-16 15:38 ` William Breathitt Gray
2022-12-14 10:31 ` [PATCH v9 4/5] counter: Add Renesas RZ/G2L MTU3a counter driver Biju Das
2022-12-16 16:01 ` William Breathitt Gray
2022-12-16 17:00 ` Biju Das
2022-12-16 17:13 ` William Breathitt Gray
2022-12-16 17:24 ` Biju Das
2022-12-16 17:34 ` William Breathitt Gray [this message]
2022-12-14 10:31 ` [PATCH v9 5/5] pwm: Add Renesas RZ/G2L MTU3a PWM driver Biju Das
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=Y5ysPT3wrc7h9x2T@fedora \
--to=william.gray@linaro.org \
--cc=Chris.Paterson2@renesas.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=geert+renesas@glider.be \
--cc=linux-iio@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
/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.