From: Maciek Machnikowski <maciek@machnikowski.net> To: Jakub Kicinski <kuba@kernel.org>, Maciek Machnikowski <maciek@machnikowski.net> Cc: Jiri Pirko <jiri@resnulli.us>, "'Kubalewski, Arkadiusz'" <arkadiusz.kubalewski@intel.com>, 'Vadim Fedorenko' <vfedorenko@novek.ru>, 'Jonathan Lemon' <jonathan.lemon@gmail.com>, 'Paolo Abeni' <pabeni@redhat.com>, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Date: Fri, 9 Dec 2022 18:11:12 +0100 [thread overview] Message-ID: <c4498ff8-74b0-a01f-d029-6e6df226bc1b@machnikowski.net> (raw) In-Reply-To: <20221209083104.2469ebd6@kernel.org> On 12/9/2022 5:31 PM, Jakub Kicinski wrote: > On Fri, 9 Dec 2022 15:09:08 +0100 Maciek Machnikowski wrote: >> On 12/9/2022 12:07 PM, Jiri Pirko wrote: >>> Looking at the documentation of the chips, they all have mupltiple DPLLs >>> on a die. Arkadiusz, in your proposed implementation, do you model each >>> DPLL separatelly? If yes, then I understand the urgency of need of a >>> shared pin. So all DPLLs sharing the pin are part of the same chip? >>> >>> Question: can we have an entity, that would be 1:1 mapped to the actual >>> device/chip here? Let's call is "a synchronizer". It would contain >>> multiple DPLLs, user-facing-sources(input_connector), >>> user-facing-outputs(output_connector), i/o pins. >>> >>> An example: >>> SYNCHRONIZER >>> >>> ┌───────────────────────────────────────┐ >>> │ │ >>> │ │ >>> SyncE in connector │ ┌─────────┐ │ SyncE out connector >>> ┌───┐ │in pin 1 │DPLL_1 │ out pin 1│ ┌───┐ >>> │ ├─────────┼──────────────┤ ├──────────────┼────┤ │ >>> │ │ │ │ │ │ │ │ >>> └───┘ │ │ │ │ └───┘ >>> │ │ │ │ >>> │ ┌──┤ │ │ >>> GNSS in connector │ │ └─────────┘ │ >>> ┌───┐ │in pin 2 │ out pin 2│ EXT SMA connector >>> │ ├─────────┼───────────┘ │ ┌───┐ >>> │ │ │ ┌───────────┼────┤ │ >>> └───┘ │ │ │ │ │ >>> │ │ │ └───┘ >>> │ │ │ >>> EXT SMA connector │ │ │ >>> ┌───┐ mux │in pin 3 ┌─────────┐ │ │ >>> │ ├────┬────┼───────────┐ │ │ │ │ >>> │ │ │ │ │ │DPLL_2 │ │ │ >>> └───┘ │ │ │ │ │ │ │ >>> │ │ └──┤ ├──┘ │ >>> │ │ │ │ │ >>> EXT SMA connector │ │ │ │ │ >>> ┌───┐ │ │ │ │ │ >>> │ ├────┘ │ └─────────┘ │ >>> │ │ │ │ >>> └───┘ └───────────────────────────────────────┘ >>> >>> Do I get that remotelly correct? >> >> It looks goot, hence two corrections are needed: >> - all inputs can go to all DPLLs, and a single source can drive more >> than one DPLL >> - The external mux for SMA connector should not be a part of the >> Synchronizer subsystem - I believe there's already a separate MUX >> subsystem in the kernel and all external connections should be handled >> by a devtree or a similar concept. >> >> The only "muxing" thing that could potentially be modeled is a >> synchronizer output to synchronizer input relation. Some synchronizers >> does that internally and can use the output of one DPLL as a source for >> another. > > My experience with DT and muxes is rapidly aging, have you worked with > those recently? From what I remember the muxes were really.. "embedded" > and static compared to what we want here. > > Using DT may work nicely for defining the topology, but for config we > still need a different mechanism. > >>> synch >>> synchronizer_register(synch) >>> dpll_1 >>> synchronizer_dpll_register(synch, dpll_1) >>> dpll_2 >>> synchronizer_dpll_register(synch, dpll_2) >>> source_pin_1 >>> synchronizer_pin_register(synch, source_pin_1) >>> output_pin_1 >>> synchronizer_pin_register(synch, output_pin_1) >>> output_pin_2 >>> synchronizer_pin_register(synch, output_pin_2) >>> >>> synch_board >>> synchronizer_board_register(synch_board) >>> synch >>> synchronizer_board_sync_register(synch_board, synch) >>> source_connector_1 >>> synchronizer_board_connector_register(synch_board, source_connector_1, source_pin_1) >>> output_connector_1 >>> synchronizer_board_connector_register(synch_board, output_connector_1, output_pin_1) >>> output_connector_2 >>> synchronizer_board_connector_register(synch_board, output_connector_2, output_pin_2) >> >> I'd rather not use pins at all - just stick to sources and outputs. Both >> can use some labels to be identifiable. > > TBH I can't comprehend your suggestion. > IIUC you want an object for a source, but my brain can't handle > modeling an external object. For instance the source could be GNSS, > but this is not the GNSS subsystem. We have a pin connected to GNSS, > not the GNSS itself. > Maybe a diagram would help? A source is just a more generic term for a frequency signal that can be used by a DPLL. For some solutions it can represent a pin, for others (integrated) it can represent an internal connection to a different DPLL/PHY/MAC/embedded oscillator or anything else that can produce periodic signal. This object will have a subset of properties listed in a previous mail: >>>> Sources can configure the expected frequency, input signal >>>> monitoring (on multiple layers), expected signal levels, input >>>> termination and so on. Outputs will need the enable flag, signal >>>> format, frequency, phase offset etc. Multiple DPLLs can reuse a >>>> single source inside the same package simultaneously. I'm absolutely not willing to connect the GNSS subsystem there :) A "pin" is too ambiguous - especially for differential inputs.
WARNING: multiple messages have this Message-ID (diff)
From: Maciek Machnikowski <maciek@machnikowski.net> To: Jakub Kicinski <kuba@kernel.org>, Maciek Machnikowski <maciek@machnikowski.net> Cc: Jiri Pirko <jiri@resnulli.us>, "'Kubalewski, Arkadiusz'" <arkadiusz.kubalewski@intel.com>, 'Vadim Fedorenko' <vfedorenko@novek.ru>, 'Jonathan Lemon' <jonathan.lemon@gmail.com>, 'Paolo Abeni' <pabeni@redhat.com>, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Date: Fri, 9 Dec 2022 18:11:12 +0100 [thread overview] Message-ID: <c4498ff8-74b0-a01f-d029-6e6df226bc1b@machnikowski.net> (raw) In-Reply-To: <20221209083104.2469ebd6@kernel.org> On 12/9/2022 5:31 PM, Jakub Kicinski wrote: > On Fri, 9 Dec 2022 15:09:08 +0100 Maciek Machnikowski wrote: >> On 12/9/2022 12:07 PM, Jiri Pirko wrote: >>> Looking at the documentation of the chips, they all have mupltiple DPLLs >>> on a die. Arkadiusz, in your proposed implementation, do you model each >>> DPLL separatelly? If yes, then I understand the urgency of need of a >>> shared pin. So all DPLLs sharing the pin are part of the same chip? >>> >>> Question: can we have an entity, that would be 1:1 mapped to the actual >>> device/chip here? Let's call is "a synchronizer". It would contain >>> multiple DPLLs, user-facing-sources(input_connector), >>> user-facing-outputs(output_connector), i/o pins. >>> >>> An example: >>> SYNCHRONIZER >>> >>> ┌───────────────────────────────────────┐ >>> │ │ >>> │ │ >>> SyncE in connector │ ┌─────────┐ │ SyncE out connector >>> ┌───┐ │in pin 1 │DPLL_1 │ out pin 1│ ┌───┐ >>> │ ├─────────┼──────────────┤ ├──────────────┼────┤ │ >>> │ │ │ │ │ │ │ │ >>> └───┘ │ │ │ │ └───┘ >>> │ │ │ │ >>> │ ┌──┤ │ │ >>> GNSS in connector │ │ └─────────┘ │ >>> ┌───┐ │in pin 2 │ out pin 2│ EXT SMA connector >>> │ ├─────────┼───────────┘ │ ┌───┐ >>> │ │ │ ┌───────────┼────┤ │ >>> └───┘ │ │ │ │ │ >>> │ │ │ └───┘ >>> │ │ │ >>> EXT SMA connector │ │ │ >>> ┌───┐ mux │in pin 3 ┌─────────┐ │ │ >>> │ ├────┬────┼───────────┐ │ │ │ │ >>> │ │ │ │ │ │DPLL_2 │ │ │ >>> └───┘ │ │ │ │ │ │ │ >>> │ │ └──┤ ├──┘ │ >>> │ │ │ │ │ >>> EXT SMA connector │ │ │ │ │ >>> ┌───┐ │ │ │ │ │ >>> │ ├────┘ │ └─────────┘ │ >>> │ │ │ │ >>> └───┘ └───────────────────────────────────────┘ >>> >>> Do I get that remotelly correct? >> >> It looks goot, hence two corrections are needed: >> - all inputs can go to all DPLLs, and a single source can drive more >> than one DPLL >> - The external mux for SMA connector should not be a part of the >> Synchronizer subsystem - I believe there's already a separate MUX >> subsystem in the kernel and all external connections should be handled >> by a devtree or a similar concept. >> >> The only "muxing" thing that could potentially be modeled is a >> synchronizer output to synchronizer input relation. Some synchronizers >> does that internally and can use the output of one DPLL as a source for >> another. > > My experience with DT and muxes is rapidly aging, have you worked with > those recently? From what I remember the muxes were really.. "embedded" > and static compared to what we want here. > > Using DT may work nicely for defining the topology, but for config we > still need a different mechanism. > >>> synch >>> synchronizer_register(synch) >>> dpll_1 >>> synchronizer_dpll_register(synch, dpll_1) >>> dpll_2 >>> synchronizer_dpll_register(synch, dpll_2) >>> source_pin_1 >>> synchronizer_pin_register(synch, source_pin_1) >>> output_pin_1 >>> synchronizer_pin_register(synch, output_pin_1) >>> output_pin_2 >>> synchronizer_pin_register(synch, output_pin_2) >>> >>> synch_board >>> synchronizer_board_register(synch_board) >>> synch >>> synchronizer_board_sync_register(synch_board, synch) >>> source_connector_1 >>> synchronizer_board_connector_register(synch_board, source_connector_1, source_pin_1) >>> output_connector_1 >>> synchronizer_board_connector_register(synch_board, output_connector_1, output_pin_1) >>> output_connector_2 >>> synchronizer_board_connector_register(synch_board, output_connector_2, output_pin_2) >> >> I'd rather not use pins at all - just stick to sources and outputs. Both >> can use some labels to be identifiable. > > TBH I can't comprehend your suggestion. > IIUC you want an object for a source, but my brain can't handle > modeling an external object. For instance the source could be GNSS, > but this is not the GNSS subsystem. We have a pin connected to GNSS, > not the GNSS itself. > Maybe a diagram would help? A source is just a more generic term for a frequency signal that can be used by a DPLL. For some solutions it can represent a pin, for others (integrated) it can represent an internal connection to a different DPLL/PHY/MAC/embedded oscillator or anything else that can produce periodic signal. This object will have a subset of properties listed in a previous mail: >>>> Sources can configure the expected frequency, input signal >>>> monitoring (on multiple layers), expected signal levels, input >>>> termination and so on. Outputs will need the enable flag, signal >>>> format, frequency, phase offset etc. Multiple DPLLs can reuse a >>>> single source inside the same package simultaneously. I'm absolutely not willing to connect the GNSS subsystem there :) A "pin" is too ambiguous - especially for differential inputs. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-09 17:11 UTC|newest] Thread overview: 172+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-29 21:37 [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-11-29 21:37 ` [RFC PATCH v4 1/4] dpll: add dpll_attr/dpll_pin_attr helper classes Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-11-29 21:37 ` [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-11-30 15:21 ` Jiri Pirko 2022-11-30 15:21 ` Jiri Pirko 2022-11-30 16:23 ` Jiri Pirko 2022-11-30 16:23 ` Jiri Pirko 2022-12-23 16:45 ` Kubalewski, Arkadiusz 2022-12-23 16:45 ` Kubalewski, Arkadiusz 2023-01-02 12:28 ` Jiri Pirko 2023-01-02 12:28 ` Jiri Pirko 2022-11-30 16:37 ` Jiri Pirko 2022-11-30 16:37 ` Jiri Pirko 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 12:39 ` Jiri Pirko 2022-12-02 12:39 ` Jiri Pirko 2022-12-02 14:54 ` Kubalewski, Arkadiusz 2022-12-02 14:54 ` Kubalewski, Arkadiusz 2022-12-02 16:15 ` Jiri Pirko 2022-12-02 16:15 ` Jiri Pirko [not found] ` <20221202212206.3619bd5f@kernel.org> 2022-12-05 10:32 ` Jiri Pirko 2022-12-05 10:32 ` Jiri Pirko 2022-12-06 0:19 ` Jakub Kicinski 2022-12-06 0:19 ` Jakub Kicinski 2022-12-06 8:50 ` Jiri Pirko 2022-12-06 8:50 ` Jiri Pirko 2022-12-06 17:27 ` Jakub Kicinski 2022-12-06 17:27 ` Jakub Kicinski 2022-12-07 13:10 ` Jiri Pirko 2022-12-07 13:10 ` Jiri Pirko 2022-12-07 16:59 ` Jakub Kicinski 2022-12-07 16:59 ` Jakub Kicinski 2022-12-08 8:14 ` Jiri Pirko 2022-12-08 8:14 ` Jiri Pirko 2022-12-08 16:19 ` Jakub Kicinski 2022-12-08 16:19 ` Jakub Kicinski 2022-12-08 16:33 ` Jiri Pirko 2022-12-08 16:33 ` Jiri Pirko 2022-12-08 17:05 ` Jakub Kicinski 2022-12-08 17:05 ` Jakub Kicinski 2022-12-09 9:29 ` Jiri Pirko 2022-12-09 9:29 ` Jiri Pirko 2022-12-09 16:19 ` Jakub Kicinski 2022-12-09 16:19 ` Jakub Kicinski 2022-12-12 13:36 ` Jiri Pirko 2022-12-12 13:36 ` Jiri Pirko 2022-12-13 18:08 ` Kubalewski, Arkadiusz 2022-12-13 18:08 ` Kubalewski, Arkadiusz 2022-12-14 7:32 ` Jiri Pirko 2022-12-14 7:32 ` Jiri Pirko 2022-11-29 21:37 ` [RFC PATCH v4 3/4] dpll: documentation on DPLL subsystem interface Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-12-02 12:43 ` kernel test robot 2022-12-19 9:13 ` Paolo Abeni 2022-12-19 9:13 ` Paolo Abeni 2023-01-12 13:45 ` Kubalewski, Arkadiusz 2023-01-12 13:45 ` Kubalewski, Arkadiusz 2022-11-29 21:37 ` [RFC PATCH v4 4/4] ptp_ocp: implement DPLL ops Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-11-30 8:30 ` kernel test robot 2022-11-30 12:41 ` Jiri Pirko 2022-11-30 12:41 ` Jiri Pirko 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 12:48 ` Jiri Pirko 2022-12-02 12:48 ` Jiri Pirko 2022-12-02 14:39 ` Kubalewski, Arkadiusz 2022-12-02 14:39 ` Kubalewski, Arkadiusz 2022-12-02 16:20 ` Jiri Pirko 2022-12-02 16:20 ` Jiri Pirko 2022-12-08 0:35 ` Kubalewski, Arkadiusz 2022-12-08 0:35 ` Kubalewski, Arkadiusz 2022-12-08 8:19 ` Jiri Pirko 2022-12-08 8:19 ` Jiri Pirko 2022-12-07 2:33 ` Jakub Kicinski 2022-12-07 2:33 ` Jakub Kicinski 2022-12-07 13:19 ` Jiri Pirko 2022-12-07 13:19 ` Jiri Pirko [not found] ` <20221207090524.3f562eeb@kernel.org> 2022-12-08 11:22 ` Jiri Pirko 2022-12-09 0:36 ` Jakub Kicinski 2022-12-09 9:32 ` Jiri Pirko 2022-11-30 12:32 ` [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Jiri Pirko 2022-11-30 12:32 ` Jiri Pirko 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 16:12 ` Jiri Pirko 2022-12-02 16:12 ` Jiri Pirko 2022-12-07 2:47 ` Jakub Kicinski 2022-12-07 2:47 ` Jakub Kicinski 2022-12-07 14:09 ` netdev.dump 2022-12-07 14:09 ` netdev.dump 2022-12-07 23:21 ` Jakub Kicinski 2022-12-07 23:21 ` Jakub Kicinski 2022-12-08 11:28 ` Jiri Pirko 2022-12-08 11:28 ` Jiri Pirko 2022-12-09 0:39 ` Jakub Kicinski 2022-12-09 0:39 ` Jakub Kicinski 2022-12-09 0:56 ` Kubalewski, Arkadiusz 2022-12-09 0:56 ` Kubalewski, Arkadiusz 2022-12-08 18:08 ` Maciek Machnikowski 2022-12-08 18:08 ` Maciek Machnikowski 2022-12-09 11:07 ` Jiri Pirko 2022-12-09 11:07 ` Jiri Pirko 2022-12-09 14:09 ` Maciek Machnikowski 2022-12-09 14:09 ` Maciek Machnikowski 2022-12-09 16:31 ` Jakub Kicinski 2022-12-09 16:31 ` Jakub Kicinski 2022-12-09 17:11 ` Maciek Machnikowski [this message] 2022-12-09 17:11 ` Maciek Machnikowski 2022-12-12 13:58 ` Jiri Pirko 2022-12-12 13:58 ` Jiri Pirko 2023-01-09 14:43 ` Kubalewski, Arkadiusz 2023-01-09 14:43 ` Kubalewski, Arkadiusz 2023-01-09 16:30 ` Jiri Pirko 2023-01-09 16:30 ` Jiri Pirko 2023-01-10 10:54 ` Kubalewski, Arkadiusz 2023-01-10 10:54 ` Kubalewski, Arkadiusz 2023-01-10 14:28 ` Jiri Pirko 2023-01-10 14:28 ` Jiri Pirko [not found] ` <645a5bfd-0092-2f39-0ff2-3ffb27ccf8fe@machnikowski.net> 2023-01-11 14:17 ` Kubalewski, Arkadiusz 2023-01-11 14:17 ` Kubalewski, Arkadiusz 2023-01-11 14:40 ` Maciek Machnikowski 2023-01-11 14:40 ` Maciek Machnikowski 2023-01-11 15:30 ` Kubalewski, Arkadiusz 2023-01-11 15:30 ` Kubalewski, Arkadiusz 2023-01-11 15:54 ` Maciek Machnikowski 2023-01-11 15:54 ` Maciek Machnikowski 2023-01-11 16:27 ` Kubalewski, Arkadiusz 2023-01-11 16:27 ` Kubalewski, Arkadiusz 2023-01-10 20:05 ` Jakub Kicinski 2023-01-10 20:05 ` Jakub Kicinski 2023-01-11 8:19 ` Jiri Pirko 2023-01-11 8:19 ` Jiri Pirko 2023-01-11 14:16 ` Kubalewski, Arkadiusz 2023-01-11 14:16 ` Kubalewski, Arkadiusz 2023-01-11 15:04 ` Jiri Pirko 2023-01-11 15:04 ` Jiri Pirko 2023-01-11 15:30 ` Kubalewski, Arkadiusz 2023-01-11 15:30 ` Kubalewski, Arkadiusz 2023-01-11 16:14 ` Jiri Pirko 2023-01-11 16:14 ` Jiri Pirko 2023-01-12 12:15 ` Kubalewski, Arkadiusz 2023-01-12 12:15 ` Kubalewski, Arkadiusz 2023-01-12 14:43 ` Jiri Pirko 2023-01-12 14:43 ` Jiri Pirko 2022-12-09 0:46 ` Kubalewski, Arkadiusz 2022-12-09 0:46 ` Kubalewski, Arkadiusz 2022-12-07 14:51 ` Jiri Pirko 2022-12-07 14:51 ` Jiri Pirko [not found] ` <20221207091946.3115742f@kernel.org> 2022-12-08 12:02 ` Jiri Pirko 2022-12-08 12:02 ` Jiri Pirko 2022-12-09 0:54 ` Jakub Kicinski 2022-12-08 18:23 ` Kubalewski, Arkadiusz 2022-12-08 18:23 ` Kubalewski, Arkadiusz 2022-12-08 0:27 ` Kubalewski, Arkadiusz 2022-12-08 0:27 ` Kubalewski, Arkadiusz 2022-12-08 11:58 ` Jiri Pirko 2022-12-08 11:58 ` Jiri Pirko 2022-12-08 23:05 ` Kubalewski, Arkadiusz 2022-12-08 23:05 ` Kubalewski, Arkadiusz 2022-12-09 10:01 ` Jiri Pirko 2022-12-09 10:01 ` Jiri Pirko 2023-01-12 12:23 ` Kubalewski, Arkadiusz 2023-01-12 12:23 ` Kubalewski, Arkadiusz 2023-01-12 14:50 ` Jiri Pirko 2023-01-12 14:50 ` Jiri Pirko 2023-01-12 19:09 ` Jakub Kicinski 2023-01-12 19:09 ` Jakub Kicinski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c4498ff8-74b0-a01f-d029-6e6df226bc1b@machnikowski.net \ --to=maciek@machnikowski.net \ --cc=arkadiusz.kubalewski@intel.com \ --cc=jiri@resnulli.us \ --cc=jonathan.lemon@gmail.com \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=vfedorenko@novek.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.