[RFC PATCH v4 0/4] Create common DPLL/clock configuration API
Jiri Pirko
jiri at resnulli.us
Thu Jan 12 06:50:46 PST 2023
Thu, Jan 12, 2023 at 01:23:29PM CET, arkadiusz.kubalewski at intel.com wrote:
>>From: Vadim Fedorenko <vfedorenko at novek.ru>
>>Sent: Tuesday, November 29, 2022 10:37 PM
>>
>>Implement common API for clock/DPLL configuration and status reporting.
>>The API utilises netlink interface as transport for commands and event
>>notifications. This API aim to extend current pin configuration and make it
>>flexible and easy to cover special configurations.
>>
>>v3 -> v4:
>> * redesign framework to make pins dynamically allocated (Arkadiusz)
>> * implement shared pins (Arkadiusz)
>>v2 -> v3:
>> * implement source select mode (Arkadiusz)
>> * add documentation
>> * implementation improvements (Jakub)
>>v1 -> v2:
>> * implement returning supported input/output types
>> * ptp_ocp: follow suggestions from Jonathan
>> * add linux-clk mailing list
>>v0 -> v1:
>> * fix code style and errors
>> * add linux-arm mailing list
>>
>>
>>Arkadiusz Kubalewski (1):
>> dpll: add dpll_attr/dpll_pin_attr helper classes
>>
>>Vadim Fedorenko (3):
>> dpll: Add DPLL framework base functions
>> dpll: documentation on DPLL subsystem interface
>> ptp_ocp: implement DPLL ops
>>
>> Documentation/networking/dpll.rst | 271 ++++++++
>> Documentation/networking/index.rst | 1 +
>> MAINTAINERS | 8 +
>> drivers/Kconfig | 2 +
>> drivers/Makefile | 1 +
>> drivers/dpll/Kconfig | 7 +
>> drivers/dpll/Makefile | 11 +
>> drivers/dpll/dpll_attr.c | 278 +++++++++
>> drivers/dpll/dpll_core.c | 760 +++++++++++++++++++++++
>> drivers/dpll/dpll_core.h | 176 ++++++
>> drivers/dpll/dpll_netlink.c | 963 +++++++++++++++++++++++++++++
>> drivers/dpll/dpll_netlink.h | 24 +
>> drivers/dpll/dpll_pin_attr.c | 456 ++++++++++++++
>> drivers/ptp/Kconfig | 1 +
>> drivers/ptp/ptp_ocp.c | 123 ++--
>> include/linux/dpll.h | 261 ++++++++
>> include/linux/dpll_attr.h | 433 +++++++++++++
>> include/uapi/linux/dpll.h | 263 ++++++++
>> 18 files changed, 4002 insertions(+), 37 deletions(-) create mode 100644
>>Documentation/networking/dpll.rst create mode 100644 drivers/dpll/Kconfig
>>create mode 100644 drivers/dpll/Makefile create mode 100644
>>drivers/dpll/dpll_attr.c create mode 100644 drivers/dpll/dpll_core.c
>>create mode 100644 drivers/dpll/dpll_core.h create mode 100644
>>drivers/dpll/dpll_netlink.c create mode 100644 drivers/dpll/dpll_netlink.h
>>create mode 100644 drivers/dpll/dpll_pin_attr.c create mode 100644
>>include/linux/dpll.h create mode 100644 include/linux/dpll_attr.h create
>>mode 100644 include/uapi/linux/dpll.h
>>
>>--
>>2.27.0
>
>New thread with regard of our yesterday's call.
>
>Is it possible to initialize a multiple output MUX?
>Yes it is. Let's consider 4 input/2 output MUX and DPLL it connects with:
> +---+
> --| |
> +---+ | |
>--| | --| D |--
> | | | P |
>--| M |-----| L |--
> | U | | L |
>--| X |-----| |--
> | | | |
>--| | --| |
> +---+ +---+
>
>Basically dpll pins are initialized and assigned ids, like:
>5 inputs (0-4), 3 outputs (5-7).
> +---+
>0--| |
> | |
>1--| D |--5
> | P |
>2--| L |--6
> | L |
>3--| |--7
> | |
>4--| |
> +---+
>
>Then we would create and register muxed pins with existing dpll pins.
>Each muxed pin is allocated and registered with each parent it can provide
>signal with, like below (number in bracket is parent idx):
> +---+
> 0--| |
> +---+ | |
> 8(2) / 9(3)---| | 1--| D |--5
> | | | P |
>10(2) / 11(3)---| M |---2--| L |--6
> | U | | L |
>12(2) / 13(3)---| X |---3--| |--7
> | | | |
>14(2) / 15(3)---| | 4--| |
> +---+ +---+
>
>Controlling the mux input/output:
>In this case selecting pin #8 would provide its signal into DPLLs input#2 and
>selecting #9 would provide its signal into DPLLs input#3.
Duplication of the mux pin (for example 8,9) seems a bit silly. What if
the mux has 8 outputs? You would have to have 8 pin indexes for each mux
input.
One thing is not clear to me. The mux outputs are fixed or selectable?
I mean, can the outputs be enabled/disabled wired to a specific mux
input?
>
>BR,
>Arkadiusz
More information about the linux-arm-kernel
mailing list