Message-ID: <202502271736515748ffda@mail.local>
Date: Thu, 27 Feb 2025 18:36:51 +0100
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: William Breathitt Gray <wbg@...nel.org>
Cc: Kamel Bouhara <kamel.bouhara@...tlin.com>,
	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 28/02/2025 00:52:34+0900, William Breathitt Gray wrote:
> 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?

BMR is already available and used by the individual drivers. The current
microchip-tcb-capture already uses it to enable qdec mode.
timer-atmel-tcb uses it to chain timers.

Note that we already have a driver for the pwm function too in
drivers/pwm/pwm-atmel-tcb.c. In fact all the other TCB drivers predate
the microchip-tcb-capture driver.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists