Date:   Mon, 22 May 2023 12:20:12 -0400
From:   William Breathitt Gray <william.gray@...aro.org>
To:     andy.shevchenko@...il.com
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-gpio@...r.kernel.org
Subject: Re: [PATCH 0/3] Add Intel 8254 Counter support

On Sat, May 20, 2023 at 12:53:51PM +0300, andy.shevchenko@...il.com wrote:
> Sun, Apr 16, 2023 at 01:36:52PM -0400, William Breathitt Gray kirjoitti:
> > The Intel 8254 PIT first appeared in the early 1980s and was used
> > initially in IBM PC compatibles. The popularity of the original Intel
> > 825x family of chips led to many subsequent variants and clones of the
> > interface in various chips and integrated circuits. Although still
> > popular, interfaces compatible with the Intel 8254 PIT are nowdays
> > typically found embedded in larger VLSI processing chips and FPGA
> > components rather than as discrete ICs.
> > 
> > This patch series introduces a library to provide support for interfaces
> > compatible with the venerable Intel 8254 Programmable Interval Timer
> > (PIT). Modules wanting access to the i8254 library should select the
> > newly introduced CONFIG_I8254 Kconfig option, and import the I8254
> > symbol namespace.
> > 
> > Support for the i8254 is added in respective follow-up patches for the
> > 104-dio-48e driver and stx104 driver whose devices feature i8254
> > compatible interfaces. Several additional dependencies are necessary for
> > the 104-dio-48e [0][1][2] and stx104 [3][4].
> > 
> > Due to the dependency requirements, I can take the i8254 introduction
> > patch through the Counter tree and provide an immutable branch that can
> > be merged to the GPIO and IIO trees; the 104-dio-48e patch and stx104
> > patch could then be picked up separately by the respective subsystem
> > maintainers.
> 
> Good job!
> 
> What I'm wondering is that. Can x86 core and others which are using that chip
> utilize (some of) the functions from the library?

Essentially we just need a regmap to register the device to the system
via devm_i8254_regmap_register(), so theoretically it would be possible
to load this driver for the integrated 8254 interface used by x86 core.
The big caveat however is that the Counter subsystem currently lacks an
in-kernel API, so registering that device would just expose the
userspace Counter sysfs and chrdev interfaces.

I suppose the interest is whether we could use the configuration
functionality of the Counter subsystem to abstract some of the hardcoded
routines and magic numbers in places like drivers/clocksource/i8253.c
and similar. Right now we wouldn't be able to do so, but perhaps in the
future if an in-kernel API is developed for the Counter subsystem then
it would be possible.

An interesting side-note about compatibility: the Intel 8253 counting
behavior differs subtly from the Intel 8254 in certain situations. For
example, suppose odd counts in Mode 3: the Intel 8253 will load the
initial count directly [0] whereas the Intel 8254 loads the initial
count minus one (an even number) [1]. This results in different maximums
and minimums: for example if the initial count is 5, the Intel 8253 will
report a maximum count of 5 and a minimum count of 2 (counting 5->4->2),
whereas the Intel 8254 will report a maximum count of 4 and a minimum
count of 0 (counting 4->2->0); same square wave is produced, but
different count values are reported.

William Breathitt Gray

[0] https://www.alldatasheet.com/datasheet-pdf/pdf/66098/INTEL/8253.html
[1] https://www.alldatasheet.com/datasheet-pdf/pdf/66099/INTEL/8254.html

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists