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:
signature.asc
Description: PGP signature
