| Message ID | 20200706114347.174452-1-kamel.bouhara@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Microchip TCB Capture driver | expand |
On Mon, 6 Jul 2020 13:43:42 +0200 Kamel Bouhara <kamel.bouhara@bootlin.com> wrote: > Hello, > > Here is a new counter driver to support Microchip TCB capture devices. > > Each SoC has two TCB blocks, each one including three independent > channels.The following series adds support for two counter modes: > increase and quadrature decoder. > > As for the atmel clocksource and pwm, the counter driver needs to fill > some tcb capabilities in order to operate with the right configuration. > This is achieved in first patch of this series. > > Please feel free to comment. As far as I can see we have all the necessary acks etc and it looks good to me as well. Shall I do an immutable branch with the whole lot or should we split it up? Patches 1 and 5 need to go through the same tree, but bindings could go via another route. I'm also fine if the whole lot goes via the appropriate soc tree if that is easier. Jonathan > > Cheers, > > Changes in v6: > - Rebased on top of v5.8-rc3 > - Added Alexandre's ack > - Added Rob's ack > > Changes in v5: > - Fix duplicate keys errors in yaml dt-schema > > Changes in v4: > - Use existing binding to document capture mode of the Microchip TCBs. > > Changes in v3: > - Updated the brand name: s/atmel/microchip/. > - Added missing kernel doc for new elements introduced in structure > atmel_tcb_config. > - Removed useless blank line > - Added an explicit clock removing path using devm_add_action_or_reset > > Changes in v2: > - Fixed first patch not applying on mainline > - Updated return code to -EINVAL when user is requesting qdec mode on > a counter device not supporting it. > - Added an error case returning -EINVAL when action edge is performed > in > qdec mode. > - Removed no need to explicity setting ops to NULL from static struct > as > it is the default value. > - Changed confusing code by using snprintf for the sake of clarity. > - Changed code to use ARRAY_SIZE so that future reviewers will know > that num_counts matches what's in the atmel_tc_count array without > having to check so themselves. > - Fixed errors reported by dt_binding_check > > Alexandre Belloni (2): > dt-bindings: atmel-tcb: convert bindings to json-schema > dt-bindings: microchip: atmel,at91rm9200-tcb: add sama5d2 compatible > > Kamel Bouhara (3): > ARM: at91: add atmel tcb capabilities > dt-bindings: counter: microchip-tcb-capture counter > counter: Add microchip TCB capture counter > > .../devicetree/bindings/mfd/atmel-tcb.txt | 56 --- > .../soc/microchip/atmel,at91rm9200-tcb.yaml | 181 ++++++++ > drivers/counter/Kconfig | 11 + > drivers/counter/Makefile | 1 + > drivers/counter/microchip-tcb-capture.c | 397 ++++++++++++++++++ > include/soc/at91/atmel_tcb.h | 5 + > 6 files changed, 595 insertions(+), 56 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt > create mode 100644 Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml > create mode 100644 drivers/counter/microchip-tcb-capture.c > > -- > 2.26.2 >
Hi Jonathan, On 12/07/2020 14:35:34+0100, Jonathan Cameron wrote: > On Mon, 6 Jul 2020 13:43:42 +0200 > Kamel Bouhara <kamel.bouhara@bootlin.com> wrote: > > > Hello, > > > > Here is a new counter driver to support Microchip TCB capture devices. > > > > Each SoC has two TCB blocks, each one including three independent > > channels.The following series adds support for two counter modes: > > increase and quadrature decoder. > > > > As for the atmel clocksource and pwm, the counter driver needs to fill > > some tcb capabilities in order to operate with the right configuration. > > This is achieved in first patch of this series. > > > > Please feel free to comment. > > As far as I can see we have all the necessary acks etc and it looks > good to me as well. > > Shall I do an immutable branch with the whole lot or should we split it > up? Patches 1 and 5 need to go through the same tree, but bindings > could go via another route. I'm also fine if the whole lot goes > via the appropriate soc tree if that is easier. > I think the best would be an immutable branch as I have another series that depends on the three preliminary patches that should go through the clocksource/tip tree this cycle: https://lore.kernel.org/linux-arm-kernel/20200710230813.1005150-1-alexandre.belloni@bootlin.com/
On Wed, 15 Jul 2020 23:30:03 +0200 Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > Hi Jonathan, > > On 12/07/2020 14:35:34+0100, Jonathan Cameron wrote: > > On Mon, 6 Jul 2020 13:43:42 +0200 > > Kamel Bouhara <kamel.bouhara@bootlin.com> wrote: > > > > > Hello, > > > > > > Here is a new counter driver to support Microchip TCB capture devices. > > > > > > Each SoC has two TCB blocks, each one including three independent > > > channels.The following series adds support for two counter modes: > > > increase and quadrature decoder. > > > > > > As for the atmel clocksource and pwm, the counter driver needs to fill > > > some tcb capabilities in order to operate with the right configuration. > > > This is achieved in first patch of this series. > > > > > > Please feel free to comment. > > > > As far as I can see we have all the necessary acks etc and it looks > > good to me as well. > > > > Shall I do an immutable branch with the whole lot or should we split it > > up? Patches 1 and 5 need to go through the same tree, but bindings > > could go via another route. I'm also fine if the whole lot goes > > via the appropriate soc tree if that is easier. > > > > I think the best would be an immutable branch as I have another series > that depends on the three preliminary patches that should go through the > clocksource/tip tree this cycle: > > https://lore.kernel.org/linux-arm-kernel/20200710230813.1005150-1-alexandre.belloni@bootlin.com/ I've pushed applied the patches to an immutable branch https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/log/?h=ib-5.8-tcb and merged that into the togreg branch of iio.git which is pushed out as testing or the autobuilders to play with it. Thanks, Jonathan > >