[RFC PATCH v4 0/4] Create common DPLL/clock configuration API
Jakub Kicinski
kuba at kernel.org
Thu Jan 12 11:09:45 PST 2023
On Thu, 12 Jan 2023 12:23:29 +0000 Kubalewski, Arkadiusz wrote:
> 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.
I agree with Jiri, the duplication seems unnecessary. My thinking would
be to handle this as follows:
+---+
0--| |
+---+ | |
10---| | 1--| D |--5
| | | P |
11---| M |-8---2--| L |--6
| U | | L |
12---| X |-9---3--| |--7
| | | |
13---| | 4--| |
+---+ +---+
Give the user the ability to both select the inputs to DPLL from
0-4 and from 10-13. If 10-13 are selected the core should give mapping
things automatically a try (but we don't need to support auto-mapping
for muxes with more than one output from the start).
There should also be an API for manually configuring muxes.
Eg.
User requests DPLL inputs: 0, 1, 10, 11
Core automatically maps 10 -> 8, 11 -> 9
User requests DPLL inputs: 0, 1, 10, 11, 12
Core responds with an error
User requests DPLL inputs: 0, 1, 2, 3
Core doesn't touch the mux
User requests mux to direct 10 -> 8
User requests mux to direct 11 -> 9
Now the config is equivalent to case #1
More information about the linux-arm-kernel
mailing list