[RFC PATCH v7 0/8] Create common DPLL configuration API

Kubalewski, Arkadiusz arkadiusz.kubalewski at intel.com
Thu May 25 06:01:34 PDT 2023


>From: Jiri Pirko <jiri at resnulli.us>
>Sent: Thursday, May 11, 2023 9:53 AM
>
>Fri, Apr 28, 2023 at 02:20:01AM CEST, vadfed at meta.com wrote:
>>From: Vadim Fedorenko <vadim.fedorenko at linux.dev>
>>
>>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.
>>
>>v6 -> v7:
>> * YAML spec:
>>   - remove nested 'pin' attribute
>>   - clean up definitions on top of the latest changes
>> * pin object:
>>   - pin xarray uses id provided by the driver
>>   - remove usage of PIN_IDX_INVALID in set function
>>   - source_pin_get() returns object instead of idx
>>   - fixes in frequency support API
>> * device and pin operations are const now
>> * small fixes in naming in Makefile and in the functions
>> * single mutex for the subsystem to avoid possible ABBA locks
>> * no special *_priv() helpers anymore, private data is passed as void*
>> * no netlink filters by name anymore, only index is supported
>> * update ptp_ocp and ice drivers to follow new API version
>> * add mlx5e driver as a new customer of the subsystem
>>v5 -> v6:
>> * rework pin part to better fit shared pins use cases
>> * add YAML spec to easy generate user-space apps
>> * simple implementation in ptp_ocp is back again
>>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
>
>Vadim, did you try ynl monitor? I think there might be something wrong
>with the yaml spec:
># ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml --
>subscribe monitor --sleep 10
>Unexpected msg id done while checking for ntf nl_len = 92 (76) nl_flags =
>0x0 nl_type = 19
>

One of the commits I have prepared already replaces old notifications with the
ones suggested previously, where format of notification is the same as format
of get command.
It works there, altough not sure if it works only for me or for everyone,
I might have done some modifications to ynl-lib itself, need to double check
that.

Thank you,
Arkadiusz



More information about the linux-arm-kernel mailing list