.../devicetree/bindings/mux/reg-mux.yaml | 28 +++- drivers/mux/mmio.c | 144 ++++++++++++++---- 2 files changed, 141 insertions(+), 31 deletions(-)
This series extends mmio-mux driver's capability to configure driver in
with extended property.
In current driver implementation, driver is parsing register's offset,
mask and value from two different device tree property which makes it
complex to specify a specific register or set of registers. Introducing
mux-reg-masks-states will make it easier to specify the same values for
particular register or set of registers.
This series is based on linux next tagged next-20250303.
Link to v1:
https://lore.kernel.org/r/20250227202206.2551305-1-c-vankar@ti.com/
Changes from v1 to v2:
- Updated dt-bindings for the required conditions as suggested by Conor
Dooley and Andrew Davis.
- Modified driver changes as pointed out by Andrew Davis.
Chintan Vankar (2):
devicetree: bindings: mux: reg-mux: Update bindings for reg-mux for
new property
mux: mmio: Extend mmio-mux driver to configure mux with new DT
property
.../devicetree/bindings/mux/reg-mux.yaml | 28 +++-
drivers/mux/mmio.c | 144 ++++++++++++++----
2 files changed, 141 insertions(+), 31 deletions(-)
--
2.34.1
Hello Peter,
I am trying to implement a driver for hardware module called Timesync
Router which is present on almost all the SoCs of Texas Instruments and
I need your advise to implement it.
Timesync Router provides a mechanism to mux M input to N outputs, where
all M inputs are selectable to be driven per N output.
________________________
| Timesync INTR +---->dma_local_events
| |
Device sync events-----> +---->pcie_cpts_hw_push
| |
cpts_genf-----> +---->cpts_hw_push
|________________________|
Diagram shows a very concise view of Timesync Router. It receives
signals from multiple modules and routes the same on the other side. To
configure the functionality, we need to program output registers of
Timesync Router to configure it with the input signal. One of the
application of Timesync Router is to generate a PPS signal for CPTS
module. Timesync Router receives periodic signals generated by CPTS
module as shown "cpts_genf" in diagram and it can be routed via Timesync
Router as a Hardware Push Events as shown "cpts_hw_push" in diagram.
The functionality of Timesync Router seems very much identical to the
mux-controller, specifically mmio driver present in the mux subsystem.
I have also posted a detailed explanation on how can we modify mmio
driver which can work as a generic driver for the hardware module
identical to Timesync Router at here:
https://lore.kernel.org/r/1ce1fc6b-fc16-4fb7-9f68-57b495aa5eae@ti.com/
I have also tried to implement this module with irq subsystem:
https://lore.kernel.org/r/20250205160119.136639-1-c-vankar@ti.com/, for
which I received a response from the Thomas Gleixner that why it cannot
be included in the irq subsystem:
https://lore.kernel.org/r/87ikp8jph9.ffs@tglx/.
After receiving feedback on the Interrupt Router implementation, I tried
to implement it as a mux-controller which seems more relevant subsystem
for Timesync Router. Can you please advise me whether it can be included
in the mux-controller subsystem or not ?
Regards,
Chintan.
On 04/03/25 15:53, Chintan Vankar wrote:
> This series extends mmio-mux driver's capability to configure driver in
> with extended property.
>
> In current driver implementation, driver is parsing register's offset,
> mask and value from two different device tree property which makes it
> complex to specify a specific register or set of registers. Introducing
> mux-reg-masks-states will make it easier to specify the same values for
> particular register or set of registers.
>
> This series is based on linux next tagged next-20250303.
>
> Link to v1:
> https://lore.kernel.org/r/20250227202206.2551305-1-c-vankar@ti.com/
>
> Changes from v1 to v2:
> - Updated dt-bindings for the required conditions as suggested by Conor
> Dooley and Andrew Davis.
> - Modified driver changes as pointed out by Andrew Davis.
>
> Chintan Vankar (2):
> devicetree: bindings: mux: reg-mux: Update bindings for reg-mux for
> new property
> mux: mmio: Extend mmio-mux driver to configure mux with new DT
> property
>
> .../devicetree/bindings/mux/reg-mux.yaml | 28 +++-
> drivers/mux/mmio.c | 144 ++++++++++++++----
> 2 files changed, 141 insertions(+), 31 deletions(-)
>
Hello Greg, I have tried to implement Timesync Router node to the suitable Subsystems (Interrupt controller and Mux-controller). Thomas has provided a feedback with a reason why Timesync Router is not suitable for irqchip. But I didn't get a proper feedback for mux- controller subsystem. Can you please help me deciding in which subsystem I should implement it, if not mux-controller can it go in drivers/misc ? Regards, Chintan. On 5/20/2025 10:59 AM, Chintan Vankar wrote: > Hello Peter, > > I am trying to implement a driver for hardware module called Timesync > Router which is present on almost all the SoCs of Texas Instruments and > I need your advise to implement it. > > Timesync Router provides a mechanism to mux M input to N outputs, where > all M inputs are selectable to be driven per N output. > > ________________________ > | Timesync INTR +---->dma_local_events > | | > Device sync events-----> +---->pcie_cpts_hw_push > | | > cpts_genf-----> +---->cpts_hw_push > |________________________| > > > Diagram shows a very concise view of Timesync Router. It receives > signals from multiple modules and routes the same on the other side. To > configure the functionality, we need to program output registers of > Timesync Router to configure it with the input signal. One of the > application of Timesync Router is to generate a PPS signal for CPTS > module. Timesync Router receives periodic signals generated by CPTS > module as shown "cpts_genf" in diagram and it can be routed via Timesync > Router as a Hardware Push Events as shown "cpts_hw_push" in diagram. > > The functionality of Timesync Router seems very much identical to the > mux-controller, specifically mmio driver present in the mux subsystem. > I have also posted a detailed explanation on how can we modify mmio > driver which can work as a generic driver for the hardware module > identical to Timesync Router at here: > https://lore.kernel.org/r/1ce1fc6b-fc16-4fb7-9f68-57b495aa5eae@ti.com/ > > I have also tried to implement this module with irq subsystem: > https://lore.kernel.org/r/20250205160119.136639-1-c-vankar@ti.com/, for > which I received a response from the Thomas Gleixner that why it cannot > be included in the irq subsystem: > https://lore.kernel.org/r/87ikp8jph9.ffs@tglx/. > > After receiving feedback on the Interrupt Router implementation, I tried > to implement it as a mux-controller which seems more relevant subsystem > for Timesync Router. Can you please advise me whether it can be included > in the mux-controller subsystem or not ? > > Regards, > Chintan. > > > > > On 04/03/25 15:53, Chintan Vankar wrote: >> This series extends mmio-mux driver's capability to configure driver in >> with extended property. >> >> In current driver implementation, driver is parsing register's offset, >> mask and value from two different device tree property which makes it >> complex to specify a specific register or set of registers. Introducing >> mux-reg-masks-states will make it easier to specify the same values for >> particular register or set of registers. >> >> This series is based on linux next tagged next-20250303. >> >> Link to v1: >> https://lore.kernel.org/r/20250227202206.2551305-1-c-vankar@ti.com/ >> >> Changes from v1 to v2: >> - Updated dt-bindings for the required conditions as suggested by Conor >> Dooley and Andrew Davis. >> - Modified driver changes as pointed out by Andrew Davis. >> >> Chintan Vankar (2): >> devicetree: bindings: mux: reg-mux: Update bindings for reg-mux for >> new property >> mux: mmio: Extend mmio-mux driver to configure mux with new DT >> property >> >> .../devicetree/bindings/mux/reg-mux.yaml | 28 +++- >> drivers/mux/mmio.c | 144 ++++++++++++++---- >> 2 files changed, 141 insertions(+), 31 deletions(-) >>
On Fri, May 30, 2025 at 10:35:24PM +0530, Vankar, Chintan wrote: > Hello Greg, > > I have tried to implement Timesync Router node to the suitable > Subsystems (Interrupt controller and Mux-controller). Thomas > has provided a feedback with a reason why Timesync Router is not > suitable for irqchip. But I didn't get a proper feedback for mux- > controller subsystem. What do you mean "proper feedback"? > Can you please help me deciding in which subsystem I should implement > it, if not mux-controller can it go in drivers/misc ? Why not mux? What's preventing that from happening? Why would misc be better? thanks, greg k-h
Hello Greg, On 5/31/2025 11:22 AM, Greg Kroah-Hartman wrote: > On Fri, May 30, 2025 at 10:35:24PM +0530, Vankar, Chintan wrote: >> Hello Greg, >> >> I have tried to implement Timesync Router node to the suitable >> Subsystems (Interrupt controller and Mux-controller). Thomas >> has provided a feedback with a reason why Timesync Router is not >> suitable for irqchip. But I didn't get a proper feedback for mux- >> controller subsystem. > > What do you mean "proper feedback"? > By proper feedback, I meant, from the comments I was not able to figure out whether Timesync Router will be acceptable in the "mux-controller" subsystem or not. >> Can you please help me deciding in which subsystem I should implement >> it, if not mux-controller can it go in drivers/misc ? > > Why not mux? What's preventing that from happening? Why would misc be > better? > Sure, if mux-controller subsystem is acceptable, I will implement the Timesync Router with that and post a series. I thought of misc, when mux-controller subsystem is not acceptable and I could not find any other subsystem which is suitable for Timesync Router. Regards, Chintan. > thanks, > > greg k-h
On Sat, May 31, 2025 at 03:07:14PM +0530, Vankar, Chintan wrote: > Hello Greg, > > On 5/31/2025 11:22 AM, Greg Kroah-Hartman wrote: > > On Fri, May 30, 2025 at 10:35:24PM +0530, Vankar, Chintan wrote: > > > Hello Greg, > > > > > > I have tried to implement Timesync Router node to the suitable > > > Subsystems (Interrupt controller and Mux-controller). Thomas > > > has provided a feedback with a reason why Timesync Router is not > > > suitable for irqchip. But I didn't get a proper feedback for mux- > > > controller subsystem. > > > > What do you mean "proper feedback"? > > > > By proper feedback, I meant, from the comments I was not able to figure > out whether Timesync Router will be acceptable in the "mux-controller" > subsystem or not. Did you submit a real patch to do so? Note, I know I do not read "RFC" patches for the most part as that implies the submitter does not feel it is ready to be merged, when I have other patches that submitters _do_ feel are ready to be merged that are still left to review. > > > Can you please help me deciding in which subsystem I should implement > > > it, if not mux-controller can it go in drivers/misc ? > > > > Why not mux? What's preventing that from happening? Why would misc be > > better? > > > > Sure, if mux-controller subsystem is acceptable, I will implement the > Timesync Router with that and post a series. Try it and see! We don't normally do "what if I did this" type of review, we want to see patches that actually work. thanks, greg k-h
© 2016 - 2026 Red Hat, Inc.