Message ID | 20230117180051.2983639-1-vadfed@meta.com (mailing list archive) |
---|---|
Headers | show |
Series | Create common DPLL/clock configuration API | expand |
>-----Original Message----- >From: Vadim Fedorenko <vadfed@meta.com> >Sent: Tuesday, January 17, 2023 7:01 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. > >v4 -> v5: > * fix code issues found during last reviews: > - replace cookie with clock id > - follow one naming schema in dpll subsys > - move function comments to dpll_core.c, fix exports > - remove single-use helper functions > - merge device register with alloc > - lock and unlock mutex on dpll device release > - move dpll_type to uapi header > - rename DPLLA_DUMP_FILTER to DPLLA_FILTER > - rename dpll_pin_state to dpll_pin_mode > - rename DPLL_MODE_FORCED to DPLL_MODE_MANUAL > - remove DPLL_CHANGE_PIN_TYPE enum value > * rewrite framework once again (Arkadiusz) > - add clock class: > Provide userspace with clock class value of DPLL with dpll device dump > netlink request. Clock class is assigned by driver allocating a dpll > device. Clock class values are defined as specified in: > ITU-T G.8273.2/Y.1368.2 recommendation. > - dpll device naming schema use new pattern: > "dpll_%s_%d_%d", where: > - %s - dev_name(parent) of parent device, > - %d (1) - enum value of dpll type, > - %d (2) - device index provided by parent device. > - new muxed/shared pin registration: > Let the kernel module to register a shared or muxed pin without >finding > it or its parent. Instead use a parent/shared pin description to find > correct pin internally in dpll_core, simplifing a dpll API > * Implement complex DPLL design in ice driver (Arkadiusz) > * Remove ptp_ocp driver from the series for now >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 (2): > ice: add admin commands to access cgu configuration > ice: implement dpll interface to control cgu > >Vadim Fedorenko (2): > dpll: documentation on DPLL subsystem interface > dpll: Add DPLL framework base functions > > Documentation/networking/dpll.rst | 280 +++ > Documentation/networking/index.rst | 1 + > MAINTAINERS | 8 + > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/dpll/Kconfig | 7 + > drivers/dpll/Makefile | 9 + > drivers/dpll/dpll_core.c | 1010 ++++++++ > drivers/dpll/dpll_core.h | 105 + > drivers/dpll/dpll_netlink.c | 883 +++++++ > drivers/dpll/dpll_netlink.h | 24 + > drivers/net/ethernet/intel/Kconfig | 1 + > drivers/net/ethernet/intel/ice/Makefile | 3 +- > drivers/net/ethernet/intel/ice/ice.h | 5 + > .../net/ethernet/intel/ice/ice_adminq_cmd.h | 240 +- > drivers/net/ethernet/intel/ice/ice_common.c | 467 ++++ > drivers/net/ethernet/intel/ice/ice_common.h | 43 + > drivers/net/ethernet/intel/ice/ice_dpll.c | 2115 +++++++++++++++++ > drivers/net/ethernet/intel/ice/ice_dpll.h | 99 + > drivers/net/ethernet/intel/ice/ice_lib.c | 17 +- > drivers/net/ethernet/intel/ice/ice_main.c | 10 + > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 408 ++++ > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 240 ++ > drivers/net/ethernet/intel/ice/ice_type.h | 1 + > include/linux/dpll.h | 282 +++ > include/uapi/linux/dpll.h | 294 +++ > 26 files changed, 6549 insertions(+), 6 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_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/net/ethernet/intel/ice/ice_dpll.c > create mode 100644 drivers/net/ethernet/intel/ice/ice_dpll.h > create mode 100644 include/linux/dpll.h create mode 100644 >include/uapi/linux/dpll.h > >-- >2.30.2 Based on today's sync meeting, changes we are going to introduce in next version: - reduce the muxed-pin number (artificial multiplication) on list of dpll's pins, have a single pin which can be connected with multiple parents, - introduce separated get command for the pin attributes, - allow infinite name length of dpll device, - remove a type embedded in dpll's name and introduce new attribute instead, - remove clock class attribute as it is not known by the driver without compliance testing on given SW/HW configuration, - add dpll device "default" quality level attribute, as shall be known by driver for a given hardware. BR, Arkadiusz
On Wed, 18 Jan 2023 18:07:53 +0000 Kubalewski, Arkadiusz wrote: > Based on today's sync meeting, changes we are going to introduce in next > version: > - reduce the muxed-pin number (artificial multiplication) on list of dpll's > pins, have a single pin which can be connected with multiple parents, > - introduce separated get command for the pin attributes, > - allow infinite name length of dpll device, > - remove a type embedded in dpll's name and introduce new attribute instead, > - remove clock class attribute as it is not known by the driver without > compliance testing on given SW/HW configuration, > - add dpll device "default" quality level attribute, as shall be known > by driver for a given hardware. I converted the patches to use the spec, and pushed them out here: https://github.com/kuba-moo/ynl/tree/dpll I kept the conversion step-by-step to help the readers a bit but the conversion patches should all be squashed into the main DPLL patch. The patches are on top of my YNL branch ('main' in that repo). I'll post the YNL patches later today, so hopefully very soon they will be upstream. Two major pieces of work which I didn't do for DPLL: - docs - I dropped most of the kdocs, the copy-n-pasting was too much; if you want to keep the docs in the uAPI you need to add the appropriate stuff in the spec (look at the definition of pin-signal-type for an example of a fully documented enum) - the notifications are quite unorthodox in the current implementation, so I faked the enums :S Usually the notification is the same as the response to a get. IIRC 'notify' and 'event' operation types should be used in the spec. There is documentation on the specs in Documentation/userspace-api/netlink/ which should give some idea of how things work. There is also another example of a spec here: https://github.com/kuba-moo/ynl/blob/psp/Documentation/netlink/specs/psp.yaml To regenerate the C code after changes to YAML: ./tools/net/ynl/ynl-regen.sh if the Python script doing the generation dies and eats the files - bring them back with: git checkout drivers/dpll/dpll_nl.c drivers/dpll/dpll_nl.h \ include/uapi/linux/dpll.h There is a "universal CLI" script in: ./tools/net/ynl/samples/cli.py which should be able to take in JSON requests and output JSON responses. I'm improvising, because I don't have any implementation to try it out, but something like: ./tools/net/ynl/samples/cli.py \ --spec Documentation/netlink/specs/dpll.yaml \ --do device-get --json '{"id": 1}' should pretty print the info about device with id 1. Actually - it probably won't because I didn't fill in all the attrs in the pin nest. But with a bit more work on the spec it should work. Would you be able to finish this conversion. Just LMK if you have any problems, the edges are definitely very sharp at this point.
Thu, Jan 19, 2023 at 01:15:25AM CET, kuba@kernel.org wrote: >On Wed, 18 Jan 2023 18:07:53 +0000 Kubalewski, Arkadiusz wrote: >> Based on today's sync meeting, changes we are going to introduce in next >> version: >> - reduce the muxed-pin number (artificial multiplication) on list of dpll's >> pins, have a single pin which can be connected with multiple parents, >> - introduce separated get command for the pin attributes, >> - allow infinite name length of dpll device, >> - remove a type embedded in dpll's name and introduce new attribute instead, >> - remove clock class attribute as it is not known by the driver without >> compliance testing on given SW/HW configuration, >> - add dpll device "default" quality level attribute, as shall be known >> by driver for a given hardware. > >I converted the patches to use the spec, and pushed them out here: > >https://github.com/kuba-moo/ynl/tree/dpll > >I kept the conversion step-by-step to help the readers a bit but >the conversion patches should all be squashed into the main DPLL patch. > >The patches are on top of my YNL branch ('main' in that repo). >I'll post the YNL patches later today, so hopefully very soon they will >be upstream. > >Two major pieces of work which I didn't do for DPLL: > - docs - I dropped most of the kdocs, the copy-n-pasting was too much; > if you want to keep the docs in the uAPI you need to add the > appropriate stuff in the spec (look at the definition of > pin-signal-type for an example of a fully documented enum) > - the notifications are quite unorthodox in the current > implementation, so I faked the enums :S > Usually the notification is the same as the response to a get. > IIRC 'notify' and 'event' operation types should be used in the spec. I already pointed this out in the past. This is not he only thing that was ignored during the dpll review. I have to say I'm a bit annoyed by that. > >There is documentation on the specs in >Documentation/userspace-api/netlink/ which should give some idea of how >things work. There is also another example of a spec here: >https://github.com/kuba-moo/ynl/blob/psp/Documentation/netlink/specs/psp.yaml > >To regenerate the C code after changes to YAML: > > ./tools/net/ynl/ynl-regen.sh > >if the Python script doing the generation dies and eats the files - >bring them back with: > > git checkout drivers/dpll/dpll_nl.c drivers/dpll/dpll_nl.h \ > include/uapi/linux/dpll.h > >There is a "universal CLI" script in: > > ./tools/net/ynl/samples/cli.py > >which should be able to take in JSON requests and output JSON responses. >I'm improvising, because I don't have any implementation to try it >out, but something like: > > ./tools/net/ynl/samples/cli.py \ > --spec Documentation/netlink/specs/dpll.yaml \ > --do device-get --json '{"id": 1}' > >should pretty print the info about device with id 1. Actually - it >probably won't because I didn't fill in all the attrs in the pin nest. >But with a bit more work on the spec it should work. > >Would you be able to finish this conversion. Just LMK if you have any >problems, the edges are definitely very sharp at this point.
>-----Original Message----- >From: Jakub Kicinski <kuba@kernel.org> >Sent: Thursday, January 19, 2023 1:15 AM > >On Wed, 18 Jan 2023 18:07:53 +0000 Kubalewski, Arkadiusz wrote: >> Based on today's sync meeting, changes we are going to introduce in next >> version: >> - reduce the muxed-pin number (artificial multiplication) on list of >dpll's >> pins, have a single pin which can be connected with multiple parents, >> - introduce separated get command for the pin attributes, >> - allow infinite name length of dpll device, >> - remove a type embedded in dpll's name and introduce new attribute >instead, >> - remove clock class attribute as it is not known by the driver without >> compliance testing on given SW/HW configuration, >> - add dpll device "default" quality level attribute, as shall be known >> by driver for a given hardware. > >I converted the patches to use the spec, and pushed them out here: > >https://github.com/kuba-moo/ynl/tree/dpll > >I kept the conversion step-by-step to help the readers a bit but >the conversion patches should all be squashed into the main DPLL patch. > >The patches are on top of my YNL branch ('main' in that repo). >I'll post the YNL patches later today, so hopefully very soon they will >be upstream. > >Two major pieces of work which I didn't do for DPLL: > - docs - I dropped most of the kdocs, the copy-n-pasting was too much; > if you want to keep the docs in the uAPI you need to add the > appropriate stuff in the spec (look at the definition of > pin-signal-type for an example of a fully documented enum) > - the notifications are quite unorthodox in the current > implementation, so I faked the enums :S > Usually the notification is the same as the response to a get. > IIRC 'notify' and 'event' operation types should be used in the spec. > >There is documentation on the specs in >Documentation/userspace-api/netlink/ which should give some idea of how >things work. There is also another example of a spec here: >https://github.com/kuba- >moo/ynl/blob/psp/Documentation/netlink/specs/psp.yaml > >To regenerate the C code after changes to YAML: > > ./tools/net/ynl/ynl-regen.sh > >if the Python script doing the generation dies and eats the files - >bring them back with: > > git checkout drivers/dpll/dpll_nl.c drivers/dpll/dpll_nl.h \ > include/uapi/linux/dpll.h > >There is a "universal CLI" script in: > > ./tools/net/ynl/samples/cli.py > >which should be able to take in JSON requests and output JSON responses. >I'm improvising, because I don't have any implementation to try it >out, but something like: > > ./tools/net/ynl/samples/cli.py \ > --spec Documentation/netlink/specs/dpll.yaml \ > --do device-get --json '{"id": 1}' > >should pretty print the info about device with id 1. Actually - it >probably won't because I didn't fill in all the attrs in the pin nest. >But with a bit more work on the spec it should work. > >Would you be able to finish this conversion. Just LMK if you have any >problems, the edges are definitely very sharp at this point. Sure, I will try. Thanks for the manual! BR, Arkadiusz