linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: William Breathitt Gray <wbg@kernel.org>
To: Kamel Bouhara <kamel.bouhara@bootlin.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	linux-iio@vger.kernel.org,
	"Ludovic Desroches" <ludovic.desroches@microchip.com>,
	linux-kernel@vger.kernel.org, Dharma.B@microchip.com,
	"Csókás Bence" <csokas.bence@prolan.hu>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 0/2] microchip-tcb-capture: Add Capture, Compare, Overflow etc. events
Date: Thu, 27 Feb 2025 23:22:36 +0900	[thread overview]
Message-ID: <Z8B1LDT-n2XTTp8q@ishi> (raw)
In-Reply-To: <20250227135330.GC182392@tpx1.home>

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

On Thu, Feb 27, 2025 at 02:53:30PM +0100, Kamel Bouhara wrote:
> On Thu, Feb 27, 2025 at 01:59:57PM +0900, William Breathitt Gray wrote:
> > Let me make sure I understand the situation correctly. This SoC has two
> > Timer Counter Blocks (TCB) and each TCB has three Timer Counter Channels
> > (TCC); each TCC has a Counter Value (CV) and three general registers
> > (RA, RB, RC); RA and RB can store Captures, and RC can be used for
> > Compare operations.
> >
> > If that is true, then the correct way for this hardware to be exposed is
> > to have each TCB be a Counter device where each TCC is exposed as a
> > Count. So for this SoC: two Counter devices as counter0 and counter1;
> > count0, count1, and count2 as the three TCC; i.e. counter0/count{0,1,2}
> > and counter1/count{0,1,2}.

[...]

> > Kamel, what would it take for us to rectify this situation so that the
> > TCC are organized together by TCB under the same Counter devices?
> 
> Hello,
> 
> Indeed, each TCC operates independently except when quadrature mode is
> enabled. I assume this approach was taken to provide more flexibility by
> exposing them separately.
> 
> Currently only one channel is configured this would need to rework the
> driver to make the 3 TCCs exposed.
> 
> Greetings,
> Kamel

Skimming through the driver, it looks like what we'll need is for
mchp_tc_counts[] to have all three TCCs defined, then have
mchp_tc_probe() match on a TCB node and configure each TCC. Once that's
setup, then whenever we need to identify which TCC a callback is
exposing, we can get it from count->id.

So for example, the TC_CV register offset is calculated as 0x00 +
channel * 0x40 + 0x10. In the count_read() callback we can leverage
count->id to identify the TCC and thus get the respective TC_CV register
at offset + count->id * 0x40 + 0x10.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2025-02-27 14:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-11 15:19 [PATCH v4 0/2] microchip-tcb-capture: Add Capture, Compare, Overflow etc. events Bence Csókás
2025-02-11 15:19 ` [PATCH v4 1/2] counter: microchip-tcb-capture: Add IRQ handling Bence Csókás
2025-02-11 15:19 ` [PATCH v4 2/2] counter: microchip-tcb-capture: Add capture extensions for registers RA-RC Bence Csókás
2025-02-21 12:39 ` [PATCH v4 0/2] microchip-tcb-capture: Add Capture, Compare, Overflow etc. events William Breathitt Gray
2025-02-21 14:14   ` Csókás Bence
2025-02-24  3:07     ` William Breathitt Gray
2025-02-26 12:58       ` Csókás Bence
2025-02-27  4:59         ` William Breathitt Gray
2025-02-27 13:53           ` Kamel Bouhara
2025-02-27 14:03             ` Kamel Bouhara
2025-02-27 14:22             ` William Breathitt Gray [this message]
2025-02-27 14:37               ` Alexandre Belloni
2025-02-27 15:12                 ` William Breathitt Gray
2025-02-27 15:52                   ` William Breathitt Gray
2025-02-27 15:56                     ` Csókás Bence
2025-02-28  0:13                       ` William Breathitt Gray
2025-02-27 17:36                     ` Alexandre Belloni
2025-02-27 14:17           ` Csókás Bence
2025-02-27 15:00             ` William Breathitt Gray

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=Z8B1LDT-n2XTTp8q@ishi \
    --to=wbg@kernel.org \
    --cc=Dharma.B@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=csokas.bence@prolan.hu \
    --cc=jic23@kernel.org \
    --cc=kamel.bouhara@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludovic.desroches@microchip.com \
    --cc=thomas.petazzoni@bootlin.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 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).