From: Jakub Kicinski <kuba@kernel.org>
To: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Cc: Vadim Fedorenko <vadfed@meta.com>, Jiri Pirko <jiri@resnulli.us>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
Milena Olech <milena.olech@intel.com>,
Michal Michalik <michal.michalik@intel.com>,
linux-arm-kernel@lists.infradead.org, poros@redhat.com,
mschmidt@redhat.com, netdev@vger.kernel.org,
linux-clk@vger.kernel.org
Subject: Re: [RFC PATCH v7 3/8] dpll: documentation on DPLL subsystem interface
Date: Fri, 5 May 2023 08:29:35 -0700 [thread overview]
Message-ID: <20230505082935.24deca78@kernel.org> (raw)
In-Reply-To: <7be22f4a-3fd5-f579-6824-56b4feafdb03@linux.dev>
On Fri, 5 May 2023 14:16:53 +0100 Vadim Fedorenko wrote:
> >> +Then there are two groups of configuration knobs:
> >> +1) Set on a pin - the configuration affects all dpll devices pin is
> >> + registered to. (i.e. ``PIN_FREQUENCY``, ``PIN_DIRECTION``),
> >
> > Why is direction set on a pin? We can't chain DPLLs?
>
> We can chain DPLLs using pins only. We don't have any interface to
> configure 2 pins to connect 2 different DPLLs to each other at the same
> time. The configuration should take care of one pin being input and
> other one being output. That's why we have direction property attached
> to the pin, not the DPLL itself.
Makes sense.
> >> +Device driver implementation
> >> +============================
> >> +
> >> +Device is allocated by ``dpll_device_get`` call. Second call with the
> >> +same arguments doesn't create new object but provides pointer to
> >> +previously created device for given arguments, it also increase refcount
> >> +of that object.
> >> +Device is deallocated by ``dpll_device_put`` call, which first decreases
> >> +the refcount, once refcount is cleared the object is destroyed.
> >
> > You can add () after the function name and render the kdoc at the end
> > of this doc. The `` marking will then be unnecessary.
> >
> Mmm... any examples of such a way of creating documentation? I was
> following tls*.rst style, but without copying code-blocks.
net_dim.rst, maybe? driver.rst ? Feel free to ping me 1:1 if you're
struggling, it should be fairly straightforward.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Cc: Vadim Fedorenko <vadfed@meta.com>, Jiri Pirko <jiri@resnulli.us>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
Milena Olech <milena.olech@intel.com>,
Michal Michalik <michal.michalik@intel.com>,
linux-arm-kernel@lists.infradead.org, poros@redhat.com,
mschmidt@redhat.com, netdev@vger.kernel.org,
linux-clk@vger.kernel.org
Subject: Re: [RFC PATCH v7 3/8] dpll: documentation on DPLL subsystem interface
Date: Fri, 5 May 2023 08:29:35 -0700 [thread overview]
Message-ID: <20230505082935.24deca78@kernel.org> (raw)
In-Reply-To: <7be22f4a-3fd5-f579-6824-56b4feafdb03@linux.dev>
On Fri, 5 May 2023 14:16:53 +0100 Vadim Fedorenko wrote:
> >> +Then there are two groups of configuration knobs:
> >> +1) Set on a pin - the configuration affects all dpll devices pin is
> >> + registered to. (i.e. ``PIN_FREQUENCY``, ``PIN_DIRECTION``),
> >
> > Why is direction set on a pin? We can't chain DPLLs?
>
> We can chain DPLLs using pins only. We don't have any interface to
> configure 2 pins to connect 2 different DPLLs to each other at the same
> time. The configuration should take care of one pin being input and
> other one being output. That's why we have direction property attached
> to the pin, not the DPLL itself.
Makes sense.
> >> +Device driver implementation
> >> +============================
> >> +
> >> +Device is allocated by ``dpll_device_get`` call. Second call with the
> >> +same arguments doesn't create new object but provides pointer to
> >> +previously created device for given arguments, it also increase refcount
> >> +of that object.
> >> +Device is deallocated by ``dpll_device_put`` call, which first decreases
> >> +the refcount, once refcount is cleared the object is destroyed.
> >
> > You can add () after the function name and render the kdoc at the end
> > of this doc. The `` marking will then be unnecessary.
> >
> Mmm... any examples of such a way of creating documentation? I was
> following tls*.rst style, but without copying code-blocks.
net_dim.rst, maybe? driver.rst ? Feel free to ping me 1:1 if you're
struggling, it should be fairly straightforward.
_______________________________________________
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:[~2023-05-05 15:30 UTC|newest]
Thread overview: 149+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 0:20 [RFC PATCH v7 0/8] Create common DPLL configuration API Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-04-28 0:20 ` [RFC PATCH v7 1/8] dpll: spec: Add Netlink spec in YAML Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-05-04 12:02 ` Jiri Pirko
2023-05-04 12:02 ` Jiri Pirko
2023-05-04 21:24 ` Jakub Kicinski
2023-05-04 21:24 ` Jakub Kicinski
2023-05-05 10:29 ` Jiri Pirko
2023-05-05 10:29 ` Jiri Pirko
2023-05-11 7:44 ` Kubalewski, Arkadiusz
2023-05-11 8:00 ` Jiri Pirko
2023-05-11 14:55 ` Jakub Kicinski
2023-05-11 7:40 ` Kubalewski, Arkadiusz
2023-05-11 7:59 ` Jiri Pirko
2023-05-11 20:51 ` Kubalewski, Arkadiusz
2023-05-15 9:30 ` Jiri Pirko
2023-05-15 9:30 ` Jiri Pirko
2023-05-16 12:05 ` Kubalewski, Arkadiusz
2023-05-16 12:05 ` Kubalewski, Arkadiusz
2023-05-16 14:33 ` Jiri Pirko
2023-05-16 14:33 ` Jiri Pirko
2023-05-18 13:24 ` Kubalewski, Arkadiusz
2023-05-18 13:24 ` Kubalewski, Arkadiusz
2023-05-18 14:02 ` Jiri Pirko
2023-05-18 14:02 ` Jiri Pirko
2023-05-11 15:20 ` Jakub Kicinski
2023-05-11 20:53 ` Kubalewski, Arkadiusz
2023-05-11 23:29 ` Jakub Kicinski
2023-05-16 12:15 ` Kubalewski, Arkadiusz
2023-05-16 12:15 ` Kubalewski, Arkadiusz
2023-05-11 7:38 ` Kubalewski, Arkadiusz
2023-05-11 8:14 ` Jiri Pirko
2023-05-11 20:53 ` Kubalewski, Arkadiusz
2023-05-11 15:26 ` Jakub Kicinski
2023-05-11 20:54 ` Kubalewski, Arkadiusz
2023-04-28 0:20 ` [RFC PATCH v7 2/8] dpll: Add DPLL framework base functions Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-05-02 15:38 ` Jiri Pirko
2023-05-02 15:38 ` Jiri Pirko
2023-06-06 18:47 ` Kubalewski, Arkadiusz
2023-06-06 18:47 ` Kubalewski, Arkadiusz
2023-05-03 8:09 ` Jiri Pirko
2023-05-03 8:09 ` Jiri Pirko
2023-06-06 18:50 ` Kubalewski, Arkadiusz
2023-06-06 18:50 ` Kubalewski, Arkadiusz
2023-05-04 11:18 ` Jiri Pirko
2023-05-04 11:18 ` Jiri Pirko
2023-05-04 20:27 ` Jakub Kicinski
2023-05-04 20:27 ` Jakub Kicinski
2023-06-06 18:55 ` Kubalewski, Arkadiusz
2023-06-06 18:55 ` Kubalewski, Arkadiusz
2023-05-04 21:21 ` Jakub Kicinski
2023-05-04 21:21 ` Jakub Kicinski
2023-06-09 12:54 ` Kubalewski, Arkadiusz
2023-06-09 12:54 ` Kubalewski, Arkadiusz
2023-05-09 13:40 ` Jiri Pirko
2023-06-09 12:53 ` Kubalewski, Arkadiusz
2023-06-09 12:53 ` Kubalewski, Arkadiusz
2023-06-13 13:49 ` Jiri Pirko
2023-06-13 13:49 ` Jiri Pirko
2023-05-22 14:45 ` Paolo Abeni
2023-05-22 14:45 ` Paolo Abeni
2023-06-09 12:51 ` Kubalewski, Arkadiusz
2023-06-09 12:51 ` Kubalewski, Arkadiusz
2023-04-28 0:20 ` [RFC PATCH v7 3/8] dpll: documentation on DPLL subsystem interface Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-05-02 7:50 ` kernel test robot
2023-05-04 19:04 ` Jakub Kicinski
2023-05-04 19:04 ` Jakub Kicinski
2023-05-05 13:16 ` Vadim Fedorenko
2023-05-05 13:16 ` Vadim Fedorenko
2023-05-05 15:29 ` Jakub Kicinski [this message]
2023-05-05 15:29 ` Jakub Kicinski
2023-05-11 10:23 ` Kubalewski, Arkadiusz
2023-04-28 0:20 ` [RFC PATCH v7 4/8] ice: add admin commands to access cgu configuration Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-04-28 3:20 ` kernel test robot
2023-04-28 17:53 ` kernel test robot
2023-04-28 0:20 ` [RFC PATCH v7 5/8] ice: implement dpll interface to control cgu Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-04-28 6:05 ` kernel test robot
2023-04-28 8:18 ` kernel test robot
2023-05-03 12:18 ` Jiri Pirko
2023-05-03 12:18 ` Jiri Pirko
2023-05-15 22:07 ` Kubalewski, Arkadiusz
2023-05-15 22:07 ` Kubalewski, Arkadiusz
2023-05-16 6:26 ` Jiri Pirko
2023-05-16 6:26 ` Jiri Pirko
2023-05-18 16:06 ` Kubalewski, Arkadiusz
2023-05-18 16:06 ` Kubalewski, Arkadiusz
2023-05-19 6:15 ` Jiri Pirko
2023-05-19 6:15 ` Jiri Pirko
2023-05-25 9:01 ` Kubalewski, Arkadiusz
2023-05-25 9:01 ` Kubalewski, Arkadiusz
2023-05-19 6:47 ` Paolo Abeni
2023-05-19 6:47 ` Paolo Abeni
2023-05-25 9:05 ` Kubalewski, Arkadiusz
2023-05-25 9:05 ` Kubalewski, Arkadiusz
2023-05-15 17:12 ` Jiri Pirko
2023-05-15 17:12 ` Jiri Pirko
2023-05-16 9:22 ` Kubalewski, Arkadiusz
2023-05-16 9:22 ` Kubalewski, Arkadiusz
2023-05-16 11:46 ` Jiri Pirko
2023-05-16 11:46 ` Jiri Pirko
2023-05-18 16:07 ` Kubalewski, Arkadiusz
2023-05-18 16:07 ` Kubalewski, Arkadiusz
2023-05-19 6:15 ` Jiri Pirko
2023-05-19 6:15 ` Jiri Pirko
2023-04-28 0:20 ` [RFC PATCH v7 6/8] ptp_ocp: implement DPLL ops Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-04-28 6:36 ` kernel test robot
2023-05-04 9:27 ` Jiri Pirko
2023-05-04 9:27 ` Jiri Pirko
2023-05-05 13:43 ` Vadim Fedorenko
2023-05-05 13:43 ` Vadim Fedorenko
2023-05-06 12:42 ` Jiri Pirko
2023-05-06 12:42 ` Jiri Pirko
2023-04-28 0:20 ` [RFC PATCH v7 7/8] netdev: expose DPLL pin handle for netdevice Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-04-28 2:36 ` Stephen Hemminger
2023-04-28 2:36 ` Stephen Hemminger
2023-04-28 10:00 ` Vadim Fedorenko
2023-04-28 10:00 ` Vadim Fedorenko
2023-04-28 2:49 ` kernel test robot
2023-04-28 3:09 ` kernel test robot
2023-05-04 20:31 ` Jakub Kicinski
2023-05-04 20:31 ` Jakub Kicinski
2023-05-05 10:32 ` Jiri Pirko
2023-05-05 10:32 ` Jiri Pirko
2023-04-28 0:20 ` [RFC PATCH v7 8/8] mlx5: Implement SyncE support using DPLL infrastructure Vadim Fedorenko
2023-04-28 0:20 ` Vadim Fedorenko
2023-05-02 8:55 ` [RFC PATCH v7 0/8] Create common DPLL configuration API Jiri Pirko
2023-05-02 8:55 ` Jiri Pirko
2023-05-02 13:04 ` Jiri Pirko
2023-05-02 13:04 ` Jiri Pirko
2023-05-25 12:52 ` Kubalewski, Arkadiusz
2023-05-25 12:52 ` Kubalewski, Arkadiusz
2023-05-11 7:52 ` Jiri Pirko
2023-05-25 13:01 ` Kubalewski, Arkadiusz
2023-05-25 13:01 ` Kubalewski, Arkadiusz
2023-05-17 10:18 ` Jiri Pirko
2023-05-17 10:18 ` Jiri Pirko
2023-05-26 10:14 ` Kubalewski, Arkadiusz
2023-05-26 10:14 ` Kubalewski, Arkadiusz
2023-05-26 10:39 ` Jiri Pirko
2023-05-26 10:39 ` Jiri Pirko
2023-06-05 10:07 ` Kubalewski, Arkadiusz
2023-06-05 10:07 ` Kubalewski, Arkadiusz
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=20230505082935.24deca78@kernel.org \
--to=kuba@kernel.org \
--cc=arkadiusz.kubalewski@intel.com \
--cc=jiri@resnulli.us \
--cc=jonathan.lemon@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=michal.michalik@intel.com \
--cc=milena.olech@intel.com \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=poros@redhat.com \
--cc=vadfed@meta.com \
--cc=vadim.fedorenko@linux.dev \
/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.