All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>
To: Jiri Pirko <jiri@resnulli.us>, Jakub Kicinski <kuba@kernel.org>
Cc: Maciek Machnikowski <maciek@machnikowski.net>,
	'Vadim Fedorenko' <vfedorenko@novek.ru>,
	'Jonathan Lemon' <jonathan.lemon@gmail.com>,
	"'Paolo Abeni'" <pabeni@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>
Subject: RE: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API
Date: Wed, 11 Jan 2023 14:16:59 +0000	[thread overview]
Message-ID: <DM6PR11MB4657AC41BBF714A280B578D49BFC9@DM6PR11MB4657.namprd11.prod.outlook.com> (raw)
In-Reply-To: <Y75xFlEDCThGtMDq@nanopsycho>

>From: Jiri Pirko <jiri@resnulli.us>
>Sent: Wednesday, January 11, 2023 9:20 AM
>
>Tue, Jan 10, 2023 at 09:05:49PM CET, kuba@kernel.org wrote:
>>On Mon, 9 Jan 2023 14:43:01 +0000 Kubalewski, Arkadiusz wrote:
>>> This is a simplified network switch board example.
>>> It has 2 synchronization channels, where each channel:
>>> - provides clk to 8 PHYs driven by separated MAC chips,
>>> - controls 2 DPLLs.
>>>
>>> Basically only given FW has control over its PHYs, so also a control
>over it's
>>> MUX inputs.
>>> All external sources are shared between the channels.
>>>
>>> This is why we believe it is not best idea to enclose multiple DPLLs
>with one
>>> object:
>>> - sources are shared even if DPLLs are not a single synchronizer chip,
>>> - control over specific MUX type input shall be controllable from
>different
>>> driver/firmware instances.
>>>
>>> As we know the proposal of having multiple DPLLs in one object was a try
>to
>>> simplify currently implemented shared pins. We fully support idea of
>having
>>> interfaces as simple as possible, but at the same time they shall be
>flexible
>>> enough to serve many use cases.
>>
>>I must be missing context from other discussions but what is this
>>proposal trying to solve? Well implemented shared pins is all we need.
>
>There is an entity containing the pins. The synchronizer chip. One
>synchronizer chip contains 1-n DPLLs. The source pins are connected
>to each DPLL (usually). What we missed in the original model was the
>synchronizer entity. If we have it, we don't need any notion of somehow
>floating pins as independent entities being attached to one or many
>DPLL refcounted, etc. The synchronizer device holds them in
>straightforward way.
>
>Example of a synchronizer chip:
>https://www.renesas.com/us/en/products/clocks-timing/jitter-attenuators-
>frequency-translation/8a34044-multichannel-dpll-dco-four-eight-
>channels#overview

Not really, as explained above, multiple separated synchronizer chips can be
connected to the same external sources.
This is why I wrote this email, to better explain need for references between
DPLLs and shared pins.
Synchronizer chip object with multiple DPLLs would have sense if the pins would
only belong to that single chip, but this is not true.
As the pins are shared between multiple DPLLs (both inside 1 integrated circuit
and between multiple integrated circuits), all of them shall have current state
of the source or output.
Pins still need to be shared same as they would be inside of one synchronizer
chip.

BR,
Arkadiusz

WARNING: multiple messages have this Message-ID (diff)
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>
To: Jiri Pirko <jiri@resnulli.us>, Jakub Kicinski <kuba@kernel.org>
Cc: Maciek Machnikowski <maciek@machnikowski.net>,
	'Vadim Fedorenko' <vfedorenko@novek.ru>,
	'Jonathan Lemon' <jonathan.lemon@gmail.com>,
	"'Paolo Abeni'" <pabeni@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>
Subject: RE: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API
Date: Wed, 11 Jan 2023 14:16:59 +0000	[thread overview]
Message-ID: <DM6PR11MB4657AC41BBF714A280B578D49BFC9@DM6PR11MB4657.namprd11.prod.outlook.com> (raw)
In-Reply-To: <Y75xFlEDCThGtMDq@nanopsycho>

>From: Jiri Pirko <jiri@resnulli.us>
>Sent: Wednesday, January 11, 2023 9:20 AM
>
>Tue, Jan 10, 2023 at 09:05:49PM CET, kuba@kernel.org wrote:
>>On Mon, 9 Jan 2023 14:43:01 +0000 Kubalewski, Arkadiusz wrote:
>>> This is a simplified network switch board example.
>>> It has 2 synchronization channels, where each channel:
>>> - provides clk to 8 PHYs driven by separated MAC chips,
>>> - controls 2 DPLLs.
>>>
>>> Basically only given FW has control over its PHYs, so also a control
>over it's
>>> MUX inputs.
>>> All external sources are shared between the channels.
>>>
>>> This is why we believe it is not best idea to enclose multiple DPLLs
>with one
>>> object:
>>> - sources are shared even if DPLLs are not a single synchronizer chip,
>>> - control over specific MUX type input shall be controllable from
>different
>>> driver/firmware instances.
>>>
>>> As we know the proposal of having multiple DPLLs in one object was a try
>to
>>> simplify currently implemented shared pins. We fully support idea of
>having
>>> interfaces as simple as possible, but at the same time they shall be
>flexible
>>> enough to serve many use cases.
>>
>>I must be missing context from other discussions but what is this
>>proposal trying to solve? Well implemented shared pins is all we need.
>
>There is an entity containing the pins. The synchronizer chip. One
>synchronizer chip contains 1-n DPLLs. The source pins are connected
>to each DPLL (usually). What we missed in the original model was the
>synchronizer entity. If we have it, we don't need any notion of somehow
>floating pins as independent entities being attached to one or many
>DPLL refcounted, etc. The synchronizer device holds them in
>straightforward way.
>
>Example of a synchronizer chip:
>https://www.renesas.com/us/en/products/clocks-timing/jitter-attenuators-
>frequency-translation/8a34044-multichannel-dpll-dco-four-eight-
>channels#overview

Not really, as explained above, multiple separated synchronizer chips can be
connected to the same external sources.
This is why I wrote this email, to better explain need for references between
DPLLs and shared pins.
Synchronizer chip object with multiple DPLLs would have sense if the pins would
only belong to that single chip, but this is not true.
As the pins are shared between multiple DPLLs (both inside 1 integrated circuit
and between multiple integrated circuits), all of them shall have current state
of the source or output.
Pins still need to be shared same as they would be inside of one synchronizer
chip.

BR,
Arkadiusz

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-01-11 14:18 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
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 [this message]
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=DM6PR11MB4657AC41BBF714A280B578D49BFC9@DM6PR11MB4657.namprd11.prod.outlook.com \
    --to=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=maciek@machnikowski.net \
    --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: link
Be 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.