[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8CKQvRjqH9lwzgO@ishi>
Date: Fri, 28 Feb 2025 00:52:34 +0900
From: William Breathitt Gray <wbg@...nel.org>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>,
Kamel Bouhara <kamel.bouhara@...tlin.com>
Cc: Csókás Bence <csokas.bence@...lan.hu>,
linux-arm-kernel@...ts.infradead.org, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, Dharma.B@...rochip.com,
Ludovic Desroches <ludovic.desroches@...rochip.com>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Jonathan Cameron <jic23@...nel.org>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v4 0/2] microchip-tcb-capture: Add Capture, Compare,
Overflow etc. events
On Fri, Feb 28, 2025 at 12:13:00AM +0900, William Breathitt Gray wrote:
> On Thu, Feb 27, 2025 at 03:37:28PM +0100, Alexandre Belloni wrote:
> > On 27/02/2025 23:22:36+0900, William Breathitt Gray wrote:
> > > 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.
> > >
> >
> > We can't do that because the TCC of a single TCB can have a mix of
> > different features. I struggled with the breakage to move away from the
> > one TCB, one feature state we had.
> > Be fore this, it was not possible to mix features on a single TCB, now,
> > we can have e.g. the clocksource on TCC 0 and 1 of TCB0 and a PWM on
> > TCC 2. mchp_tc_probe must not match on a TCB node...
>
> Okay I see what you mean, if we match on a TCB mode then we wouldn't be
> able to define the cases where one TCC is different from the next in the
> same TCB.
>
> The goal however isn't to support all functionality (i.e. PWM-related
> settings, etc.) in the counter driver, but just expose the TCB
> configuration options that affect the TCCs when configured for counter
> mode. For example, the sysfs attributes can be created, but they don't
> have to be available until the TCC is in the appropriate mode (e.g.
> return -EBUSY until they are in a counter mode).
>
> Is there a way to achieve that? Maybe there's a way we can populate the
> sysfs tree on the first encountered TCC, and then somehow indicate when
> additional TCCs match. Attributes can become available then dynamically
> based on the TCCs that match.
>
> William Breathitt Gray
Sorry, let me step back for a moment because maybe I'm trying to solve
a problem that might not actually be a problem.
I see functionality settings available in the TC Block Mode Register
(BMR) that can affect multiple TCCs at a time. Are these BMR settings
exposed already to users in someway? If not, do we have a way to
introduce these settings if someone wants them; e.g. would the
AutoCorrection function enable bit be exposed as a sysfs attribute, or
configured in the devicetree?
Finally, if there's not much interest in general for exposing these BMR
settings, then I suppose there is no need to change how things are right
now with the microchip-tcb-capture module and we can just keep it the
way it is. That's my only concern, whether there are users that want to
control these settings but don't have a way right now.
William Breathitt Gray
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists