Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
>From: Vitaly Grinberg >Sent: Thursday, January 15, 2026 6:26 PM > >On Thu, Jan 15, 2026 at 5:30 PM Kubalewski, Arkadiusz > wrote: >> >> >From: Vitaly Grinberg >> >Sent: Thursday, January 15, 2026 9:58 AM >> > >> >, the ea >> > >> >On Wed, Jan 14, 2026 at 3:32 PM Kubalewski, Arkadiusz >> > wrote: >> >> >> >> >From: Vitaly Grinberg >> >> >Sent: Wednesday, January 14, 2026 12:39 PM >> >> > >> >> >> >> [..] >> >> >> >> >> > >> >> >> >I see a few challenges for the user here. The biggest one is that >> >> >> >the >> >> >> >application can't tell the difference between a device that will >> >> >> >report >> >> >> >phase offsets and this unmanaged device that never will. >> >> >> >A possible way forward would be adding a capability flag to the >> >> >> >DPLL >> >> >> >API >> >> >> >so >> >> >> >users don't have to guess. >> >> >> >> >> >> There is no phase-offset field as pointed in the above example. >> >> >> No 'phase-offset' attribute -> no such capability. >> >> >> Why isn’t that enough? >> >> > >> >> >Pin reply does not contain phase offset, so no change notifications >> >> >are expected? >> >> >Could there be devices that don't report phase offset, but report >> >> >state >> >> >changes? >> >> >Is this the intended use of the phase offset API to be interpreted >> >> >as >> >> >a general pin >> >> >notification capability flag? >> >> > >> >> >> >> Sorry, this is not what I meant. >> >> >> >> The E810 produces notifications not only for the pin's phase offset >> >> but >> >> also for other pin attribute changes. When it comes to the E810 pins, >> >> notifications generated by phase offset changes are quite frequent. >> >> However, it wasn't intention to produce them every second; this is >> >> simply >> >> the result of frequent phase offset changes. >> >> >> >> Typically, the pin state changes for the pin, but for E830, the >> >> unmanaged >> >> mode means that the state of the pin never changes, resulting in no >> >> pin >> >> notifications being produced in the end. >> >> >> >> Hope that clears things up. >> > >> >Will the reported pin state remain "connected" even if I disconnect >> >the input signal? >> >Is there any information in DPLL or pin replies that can tell the user >> >"this DPLL is unmanaged type, it behaves differently"? >> >> You really cannot disconnect anything there, it is always connected, >> and no one can change it. It only shows the user actual physical >> connections hardwired into the NIC/dpll. There is no SW handled config >> possible on those. As provided in the commit message, the pins have >> empty >> capabilities set: 'capabilities': set(), thus not possible to change >> state >> by the user. >> > >Got it, thanks for clarification! > I am glad I could help. >> > >> >> >> >> >> >> >> >> >However, the preferred solution would be to simply mirror the >> >> >> >E810 >> >> >> >behavior >> >> >> >(sending phase offset). This preserves the existing API contract >> >> >> >and >> >> >> >prevents users, who have already built applications for this >> >> >> >interface, >> >> >> >from needing to implement special handling for a new hardware >> >> >> >variant >> >> >> >that >> >> >> >behaves differently. >> >> >> >> >> >> This is not currently possible from driver perspective. >> >> >> We miss the FW API for it. >> >> >> >> >> >> >There are additional inconsistencies in the existing structure I >> >> >> >wanted >> >> >> >to >> >> >> >bring to your attention. >> >> >> >1. I'm not entirely sure how a 1588-TIME_SYNC pin can have a >> >> >> >parent >> >> >> >device >> >> >> >of type "eec". EEC is all about frequency synchronization, and >> >> >> >yet >> >> >> >the >> >> >> >pin >> >> >> >named 1588-TIME_SYNC is clearly a phase pin. This also doesn't >> >> >> >play >> >> >> >well >> >> >> >with existing implementations, where EEC circuits deal with >> >> >> >frequency, >> >> >> >PPS >> >> >> >circuits deal with phase, and there is clear distinction between >> >> >> >the >> >> >> >two >> >> >> >with regard to the meaning of "being locked". >> >> >> >> >> >> This dpll device type was established based on the main purpose of >> >> >> >dpll >> >> >> device which is to drive the network ports phy clocks with it. >> >> > >> >> >What is the physical meaning of this indication (lock-status': >> >> >'locked')? Locked on what? >> >> >> >> Lock status is dpll device property. >> >> >> >> But full picture has to be determined from the list of pins, for this >> >> particular case, one input provided from host through pci-e pin, >> >> 10MHz >> >> bandwidth frequency and 1 PPS sync pulses. >> >> >> >> As already pointed the type of dpll shall let user know the purpose >> >> of >> >> the dpll existence instead of particular input properties. >> >> Input properties are determined with the pin's attributes. >> >> >> >> >As a user of this circuit I want to know that the device is locked >> >> >on >> >> >the phase of the input signal with a certain precision. >> >> >Is this the meaning of "locked" here? Can an
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
On Thu, Jan 15, 2026 at 5:30 PM Kubalewski, Arkadiusz wrote: > > >From: Vitaly Grinberg > >Sent: Thursday, January 15, 2026 9:58 AM > > > >, the ea > > > >On Wed, Jan 14, 2026 at 3:32 PM Kubalewski, Arkadiusz > > wrote: > >> > >> >From: Vitaly Grinberg > >> >Sent: Wednesday, January 14, 2026 12:39 PM > >> > > >> > >> [..] > >> > >> >> > > >> >> >I see a few challenges for the user here. The biggest one is that > >> >> >the > >> >> >application can't tell the difference between a device that will > >> >> >report > >> >> >phase offsets and this unmanaged device that never will. > >> >> >A possible way forward would be adding a capability flag to the DPLL > >> >> >API > >> >> >so > >> >> >users don't have to guess. > >> >> > >> >> There is no phase-offset field as pointed in the above example. > >> >> No 'phase-offset' attribute -> no such capability. > >> >> Why isn’t that enough? > >> > > >> >Pin reply does not contain phase offset, so no change notifications > >> >are expected? > >> >Could there be devices that don't report phase offset, but report state > >> >changes? > >> >Is this the intended use of the phase offset API to be interpreted as > >> >a general pin > >> >notification capability flag? > >> > > >> > >> Sorry, this is not what I meant. > >> > >> The E810 produces notifications not only for the pin's phase offset but > >> also for other pin attribute changes. When it comes to the E810 pins, > >> notifications generated by phase offset changes are quite frequent. > >> However, it wasn't intention to produce them every second; this is > >simply > >> the result of frequent phase offset changes. > >> > >> Typically, the pin state changes for the pin, but for E830, the > >> unmanaged > >> mode means that the state of the pin never changes, resulting in no pin > >> notifications being produced in the end. > >> > >> Hope that clears things up. > > > >Will the reported pin state remain "connected" even if I disconnect > >the input signal? > >Is there any information in DPLL or pin replies that can tell the user > >"this DPLL is unmanaged type, it behaves differently"? > > You really cannot disconnect anything there, it is always connected, > and no one can change it. It only shows the user actual physical > connections hardwired into the NIC/dpll. There is no SW handled config > possible on those. As provided in the commit message, the pins have empty > capabilities set: 'capabilities': set(), thus not possible to change state > by the user. > Got it, thanks for clarification! > > > >> > >> >> > >> >> >However, the preferred solution would be to simply mirror the E810 > >> >> >behavior > >> >> >(sending phase offset). This preserves the existing API contract and > >> >> >prevents users, who have already built applications for this > >> >> >interface, > >> >> >from needing to implement special handling for a new hardware > >> >> >variant > >> >> >that > >> >> >behaves differently. > >> >> > >> >> This is not currently possible from driver perspective. > >> >> We miss the FW API for it. > >> >> > >> >> >There are additional inconsistencies in the existing structure I > >> >> >wanted > >> >> >to > >> >> >bring to your attention. > >> >> >1. I'm not entirely sure how a 1588-TIME_SYNC pin can have a parent > >> >> >device > >> >> >of type "eec". EEC is all about frequency synchronization, and yet > >> >> >the > >> >> >pin > >> >> >named 1588-TIME_SYNC is clearly a phase pin. This also doesn't play > >> >> >well > >> >> >with existing implementations, where EEC circuits deal with > >> >> >frequency, > >> >> >PPS > >> >> >circuits deal with phase, and there is clear distinction between the > >> >> >two > >> >> >with regard to the meaning of "being locked". > >> >> > >> >> This dpll device type was established based on the main purpose of > >> >> >dpll > >> >> device which is to drive the network ports phy clocks with it. > >> > > >> >What is the physical meaning of this indication (lock-status': > >> >'locked')? Locked on what? > >> > >> Lock status is dpll device property. > >> > >> But full picture has to be determined from the list of pins, for this > >> particular case, one input provided from host through pci-e pin, 10MHz > >> bandwidth frequency and 1 PPS sync pulses. > >> > >> As already pointed the type of dpll shall let user know the purpose of > >> the dpll existence instead of particular input properties. > >> Input properties are determined with the pin's attributes. > >> > >> >As a user of this circuit I want to know that the device is locked on > >> >the phase of the input signal with a certain precision. > >> >Is this the meaning of "locked" here? Can an EEC device be locked on > >> >the Phase of the input signal? > >> > >> Well I don't have any data on the precision of such, but AFAIK it can. > >> EEC dpll shall be producing stable signal, the input it uses is only > >> part of the full dpll device picture. > >> > >> >Users of other devices (e810, zl3073x) may have implemented logic to > >
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
>From: Vitaly Grinberg >Sent: Thursday, January 15, 2026 9:58 AM > >, the ea > >On Wed, Jan 14, 2026 at 3:32 PM Kubalewski, Arkadiusz > wrote: >> >> >From: Vitaly Grinberg >> >Sent: Wednesday, January 14, 2026 12:39 PM >> > >> >> [..] >> >> >> > >> >> >I see a few challenges for the user here. The biggest one is that >> >> >the >> >> >application can't tell the difference between a device that will >> >> >report >> >> >phase offsets and this unmanaged device that never will. >> >> >A possible way forward would be adding a capability flag to the DPLL >> >> >API >> >> >so >> >> >users don't have to guess. >> >> >> >> There is no phase-offset field as pointed in the above example. >> >> No 'phase-offset' attribute -> no such capability. >> >> Why isn’t that enough? >> > >> >Pin reply does not contain phase offset, so no change notifications >> >are expected? >> >Could there be devices that don't report phase offset, but report state >> >changes? >> >Is this the intended use of the phase offset API to be interpreted as >> >a general pin >> >notification capability flag? >> > >> >> Sorry, this is not what I meant. >> >> The E810 produces notifications not only for the pin's phase offset but >> also for other pin attribute changes. When it comes to the E810 pins, >> notifications generated by phase offset changes are quite frequent. >> However, it wasn't intention to produce them every second; this is >simply >> the result of frequent phase offset changes. >> >> Typically, the pin state changes for the pin, but for E830, the >> unmanaged >> mode means that the state of the pin never changes, resulting in no pin >> notifications being produced in the end. >> >> Hope that clears things up. > >Will the reported pin state remain "connected" even if I disconnect >the input signal? >Is there any information in DPLL or pin replies that can tell the user >"this DPLL is unmanaged type, it behaves differently"? You really cannot disconnect anything there, it is always connected, and no one can change it. It only shows the user actual physical connections hardwired into the NIC/dpll. There is no SW handled config possible on those. As provided in the commit message, the pins have empty capabilities set: 'capabilities': set(), thus not possible to change state by the user. > >> >> >> >> >> >However, the preferred solution would be to simply mirror the E810 >> >> >behavior >> >> >(sending phase offset). This preserves the existing API contract and >> >> >prevents users, who have already built applications for this >> >> >interface, >> >> >from needing to implement special handling for a new hardware >> >> >variant >> >> >that >> >> >behaves differently. >> >> >> >> This is not currently possible from driver perspective. >> >> We miss the FW API for it. >> >> >> >> >There are additional inconsistencies in the existing structure I >> >> >wanted >> >> >to >> >> >bring to your attention. >> >> >1. I'm not entirely sure how a 1588-TIME_SYNC pin can have a parent >> >> >device >> >> >of type "eec". EEC is all about frequency synchronization, and yet >> >> >the >> >> >pin >> >> >named 1588-TIME_SYNC is clearly a phase pin. This also doesn't play >> >> >well >> >> >with existing implementations, where EEC circuits deal with >> >> >frequency, >> >> >PPS >> >> >circuits deal with phase, and there is clear distinction between the >> >> >two >> >> >with regard to the meaning of "being locked". >> >> >> >> This dpll device type was established based on the main purpose of >> >> >dpll >> >> device which is to drive the network ports phy clocks with it. >> > >> >What is the physical meaning of this indication (lock-status': >> >'locked')? Locked on what? >> >> Lock status is dpll device property. >> >> But full picture has to be determined from the list of pins, for this >> particular case, one input provided from host through pci-e pin, 10MHz >> bandwidth frequency and 1 PPS sync pulses. >> >> As already pointed the type of dpll shall let user know the purpose of >> the dpll existence instead of particular input properties. >> Input properties are determined with the pin's attributes. >> >> >As a user of this circuit I want to know that the device is locked on >> >the phase of the input signal with a certain precision. >> >Is this the meaning of "locked" here? Can an EEC device be locked on >> >the Phase of the input signal? >> >> Well I don't have any data on the precision of such, but AFAIK it can. >> EEC dpll shall be producing stable signal, the input it uses is only >> part of the full dpll device picture. >> >> >Users of other devices (e810, zl3073x) may have implemented logic to >> >determine the phase lock by >> >enforcing the pin parent device type as PPS. How should they change it >> >to determine phase lock (and why)? >> > >> >> I am Sorry, I don't understand the example above, could you please >> Elaborate on details of such setup? > >Yep, gladly! >Telco customers rely on the Phase being locked on the reference with a >cer
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
, the ea On Wed, Jan 14, 2026 at 3:32 PM Kubalewski, Arkadiusz wrote: > > >From: Vitaly Grinberg > >Sent: Wednesday, January 14, 2026 12:39 PM > > > > [..] > > >> > > >> >I see a few challenges for the user here. The biggest one is that the > >> >application can't tell the difference between a device that will report > >> >phase offsets and this unmanaged device that never will. > >> >A possible way forward would be adding a capability flag to the DPLL API > >> >so > >> >users don't have to guess. > >> > >> There is no phase-offset field as pointed in the above example. > >> No 'phase-offset' attribute -> no such capability. > >> Why isn’t that enough? > > > >Pin reply does not contain phase offset, so no change notifications > >are expected? > >Could there be devices that don't report phase offset, but report state > >changes? > >Is this the intended use of the phase offset API to be interpreted as > >a general pin > >notification capability flag? > > > > Sorry, this is not what I meant. > > The E810 produces notifications not only for the pin's phase offset but > also for other pin attribute changes. When it comes to the E810 pins, > notifications generated by phase offset changes are quite frequent. > However, it wasn't intention to produce them every second; this is simply > the result of frequent phase offset changes. > > Typically, the pin state changes for the pin, but for E830, the unmanaged > mode means that the state of the pin never changes, resulting in no pin > notifications being produced in the end. > > Hope that clears things up. Will the reported pin state remain "connected" even if I disconnect the input signal? Is there any information in DPLL or pin replies that can tell the user "this DPLL is unmanaged type, it behaves differently"? > > >> > >> >However, the preferred solution would be to simply mirror the E810 > >> >behavior > >> >(sending phase offset). This preserves the existing API contract and > >> >prevents users, who have already built applications for this interface, > >> >from needing to implement special handling for a new hardware variant > >> >that > >> >behaves differently. > >> > >> This is not currently possible from driver perspective. > >> We miss the FW API for it. > >> > >> >There are additional inconsistencies in the existing structure I wanted > >> >to > >> >bring to your attention. > >> >1. I'm not entirely sure how a 1588-TIME_SYNC pin can have a parent > >> >device > >> >of type "eec". EEC is all about frequency synchronization, and yet the > >> >pin > >> >named 1588-TIME_SYNC is clearly a phase pin. This also doesn't play well > >> >with existing implementations, where EEC circuits deal with frequency, > >> >PPS > >> >circuits deal with phase, and there is clear distinction between the two > >> >with regard to the meaning of "being locked". > >> > >> This dpll device type was established based on the main purpose of dpll > >> device which is to drive the network ports phy clocks with it. > > > >What is the physical meaning of this indication (lock-status': > >'locked')? Locked on what? > > Lock status is dpll device property. > > But full picture has to be determined from the list of pins, for this > particular case, one input provided from host through pci-e pin, 10MHz > bandwidth frequency and 1 PPS sync pulses. > > As already pointed the type of dpll shall let user know the purpose of > the dpll existence instead of particular input properties. > Input properties are determined with the pin's attributes. > > >As a user of this circuit I want to know that the device is locked on > >the phase of the input signal with a certain precision. > >Is this the meaning of "locked" here? Can an EEC device be locked on > >the Phase of the input signal? > > Well I don't have any data on the precision of such, but AFAIK it can. > EEC dpll shall be producing stable signal, the input it uses is only > part of the full dpll device picture. > > >Users of other devices (e810, zl3073x) may have implemented logic to > >determine the phase lock by > >enforcing the pin parent device type as PPS. How should they change it > >to determine phase lock (and why)? > > > > I am Sorry, I don't understand the example above, could you please > Elaborate on details of such setup? Yep, gladly! Telco customers rely on the Phase being locked on the reference with a certain precision. In E810 and zl3073x the equation is simple: 1. "eec locked" means synTonization achieved - frequency locked 2. "pps locked" means synChronization achieved - phase locked The T-BC application checks the reported device type. If the device type is "pps", the report is processed by the synchronization state decision logic. Otherwise, the report doesn't have any meaning within "T-BC without SyncE" context and is discarded. Since this patch is going to create eec reports only, they are all going to be discarded, and this is a compatibility issue I'm trying to address. Could you please answer my question above: W
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
>From: Vitaly Grinberg
>Sent: Wednesday, January 14, 2026 12:39 PM
>
[..]
>> >
>> >I see a few challenges for the user here. The biggest one is that the
>> >application can't tell the difference between a device that will report
>> >phase offsets and this unmanaged device that never will.
>> >A possible way forward would be adding a capability flag to the DPLL API
>> >so
>> >users don't have to guess.
>>
>> There is no phase-offset field as pointed in the above example.
>> No 'phase-offset' attribute -> no such capability.
>> Why isn’t that enough?
>
>Pin reply does not contain phase offset, so no change notifications
>are expected?
>Could there be devices that don't report phase offset, but report state
>changes?
>Is this the intended use of the phase offset API to be interpreted as
>a general pin
>notification capability flag?
>
Sorry, this is not what I meant.
The E810 produces notifications not only for the pin's phase offset but
also for other pin attribute changes. When it comes to the E810 pins,
notifications generated by phase offset changes are quite frequent.
However, it wasn't intention to produce them every second; this is simply
the result of frequent phase offset changes.
Typically, the pin state changes for the pin, but for E830, the unmanaged
mode means that the state of the pin never changes, resulting in no pin
notifications being produced in the end.
Hope that clears things up.
>>
>> >However, the preferred solution would be to simply mirror the E810
>> >behavior
>> >(sending phase offset). This preserves the existing API contract and
>> >prevents users, who have already built applications for this interface,
>> >from needing to implement special handling for a new hardware variant
>> >that
>> >behaves differently.
>>
>> This is not currently possible from driver perspective.
>> We miss the FW API for it.
>>
>> >There are additional inconsistencies in the existing structure I wanted
>> >to
>> >bring to your attention.
>> >1. I'm not entirely sure how a 1588-TIME_SYNC pin can have a parent
>> >device
>> >of type "eec". EEC is all about frequency synchronization, and yet the
>> >pin
>> >named 1588-TIME_SYNC is clearly a phase pin. This also doesn't play well
>> >with existing implementations, where EEC circuits deal with frequency,
>> >PPS
>> >circuits deal with phase, and there is clear distinction between the two
>> >with regard to the meaning of "being locked".
>>
>> This dpll device type was established based on the main purpose of dpll
>> device which is to drive the network ports phy clocks with it.
>
>What is the physical meaning of this indication (lock-status':
>'locked')? Locked on what?
Lock status is dpll device property.
But full picture has to be determined from the list of pins, for this
particular case, one input provided from host through pci-e pin, 10MHz
bandwidth frequency and 1 PPS sync pulses.
As already pointed the type of dpll shall let user know the purpose of
the dpll existence instead of particular input properties.
Input properties are determined with the pin's attributes.
>As a user of this circuit I want to know that the device is locked on
>the phase of the input signal with a certain precision.
>Is this the meaning of "locked" here? Can an EEC device be locked on
>the Phase of the input signal?
Well I don't have any data on the precision of such, but AFAIK it can.
EEC dpll shall be producing stable signal, the input it uses is only
part of the full dpll device picture.
>Users of other devices (e810, zl3073x) may have implemented logic to
>determine the phase lock by
>enforcing the pin parent device type as PPS. How should they change it
>to determine phase lock (and why)?
>
I am Sorry, I don't understand the example above, could you please
Elaborate on details of such setup?
Thank you!
Arkadiusz
>>
>> >2. Since it is also an external embedded sync input pin, could it be
>> >possible to expose this information and include `esync-frequency` and
>> >`esync-pulse`? That could be useful for configuring the leading DPLL
>> >that
>> >drives the unmanaged one.
>>
>> Sure, esync caps should be provided, as the commit message example shown:
>> +'esync-frequency': 1,
>> +'esync-frequency-supported': [{'frequency-max': 1, 'frequency-min':
>>1}],
>> +'esync-pulse': 25,
>>
>
>Oh, I must have missed that.
>Thanks!
>Vitaly
>
>> Thank you!
>> Arkadiusz
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
On Wed, Jan 14, 2026 at 12:23 PM Kubalewski, Arkadiusz wrote: > > >From: Vitaly Grinberg > >Sent: Saturday, January 10, 2026 10:29 PM > > > >Hi Grzegors, > >Thanks very much for your reply! Added some clarifications inline. > > > >On Wed, Jan 7, 2026 at 11:33 PM Nitka, Grzegorz > >wrote: > >> > >> > -Original Message- > >> > From: Vitaly Grinberg > >> > Sent: Tuesday, December 16, 2025 3:42 PM > >> > To: Nitka, Grzegorz > >> > Cc: Loktionov, Aleksandr ; Nguyen, > >> > Anthony L ; Kubalewski, Arkadiusz > >> > ; [email protected]; intel-wired- > >> > [email protected]; [email protected]; linux- > >> > [email protected]; [email protected]; > >> > [email protected]; Kitszel, Przemyslaw > >> > > >> > Subject: Re:[Intel-wired-lan] [PATCH v5 iwl-next] ice: add support > >> > for unmanaged DPLL on E830 NIC > >> > > >> > Will a notification be provided when the lock is re-acquired? > >> > > >> > >> Hi Vitaly, thanks for your comments. > >> We discussed it offline already, but I think I need more clarifications. > >> > >> Regarding above question ... yes, 'lock' recovery shall be reported in > >>the same way. > >> Maybe the name of health status is a little bit misleading > >> (ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK), > >> However health_info struct contains the current lock status (either > >>'locked' or 'unlocked'). > > > >Great, thanks for clarifying this! > > > >> > Another concern is the absence of periodical pin notifications. With > >> > the E810, users received the active pin notifications every 1 > >> > second. However, the unmanaged DPLL appears to lack this > >> > functionality. User implementations currently rely on these > >> > periodical notifications to derive the overall clock state, metrics > >> > and events from the phase offset. It seems that unmanaged DPLL users > >> > will be forced to support two distinct types of DPLLs: one that > >> > sends periodical pin notifications and one that does not. Crucially, > >> > this difference does not appear to be reflected in the device > >> > capabilities, meaning users cannot know in advance whether to expect > >> > these notifications. > >> > >> After reading it one more time, I'm not sure if I get it right in the > >> first place. > >> With this patch implementation, there is dpll change notification > >> applied. > >> By dpll notification I mean calling dpll_device_change_ntf function. > >> Isn't it what you're looking for? > >> Notification is triggered only in case when lock status has changed. > >> It's unmanaged DPLL so the implementation is a little bit simplified, > >> based on FW notification. > >> There is no need for polling thread like it's done for E810. > >> But even in case of E810, where polling is applied (2 samples per > >> second), notification is triggered only in case of dpll/pin status > >> change, not every 1 second. > >> So please clarify, so either I don't understand the question (please > >> note, I'm only covering the main author) or notification mechanism, at > >> least about dpll lock state, is already implemented. > >> > > > >Yes, device lock status change notification is definitely what we are > >looking for, but there is more. Let me clarify the user perspective. > >The e810-based telco system relies on both device and pin notifications. > >Phase offset included in pin notifications is critical because the e810 > >DPLL "Locked" state is too coarse for Telco requirements. > >It is true that pin notifications are only sent on change; however, since > >the phase offset varies slightly with every measurement, the driver detects > >a change every second. This effectively turns the event-driven notification > >into a periodic one. The e810-based application strongly relies on the fact > >that phase offset notifications are unsolicited and the driver sends them > >from time to time. > >Now, with the unmanaged DPLL, no pin notification will be sent. Last time I > >checked, the device and pin information looked like this: > >Device: > > {'clock-id': 1165870453030569040, > > 'id': 4, > > 'lock-status': 'locked', > > 'm
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
>From: Vitaly Grinberg >Sent: Saturday, January 10, 2026 10:29 PM > >Hi Grzegors, >Thanks very much for your reply! Added some clarifications inline. > >On Wed, Jan 7, 2026 at 11:33 PM Nitka, Grzegorz >wrote: >> >> > -Original Message- >> > From: Vitaly Grinberg >> > Sent: Tuesday, December 16, 2025 3:42 PM >> > To: Nitka, Grzegorz >> > Cc: Loktionov, Aleksandr ; Nguyen, >> > Anthony L ; Kubalewski, Arkadiusz >> > ; [email protected]; intel-wired- >> > [email protected]; [email protected]; linux- >> > [email protected]; [email protected]; >> > [email protected]; Kitszel, Przemyslaw >> > >> > Subject: Re:[Intel-wired-lan] [PATCH v5 iwl-next] ice: add support >> > for unmanaged DPLL on E830 NIC >> > >> > Will a notification be provided when the lock is re-acquired? >> > >> >> Hi Vitaly, thanks for your comments. >> We discussed it offline already, but I think I need more clarifications. >> >> Regarding above question ... yes, 'lock' recovery shall be reported in >>the same way. >> Maybe the name of health status is a little bit misleading >> (ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK), >> However health_info struct contains the current lock status (either >>'locked' or 'unlocked'). > >Great, thanks for clarifying this! > >> > Another concern is the absence of periodical pin notifications. With >> > the E810, users received the active pin notifications every 1 >> > second. However, the unmanaged DPLL appears to lack this >> > functionality. User implementations currently rely on these >> > periodical notifications to derive the overall clock state, metrics >> > and events from the phase offset. It seems that unmanaged DPLL users >> > will be forced to support two distinct types of DPLLs: one that >> > sends periodical pin notifications and one that does not. Crucially, >> > this difference does not appear to be reflected in the device >> > capabilities, meaning users cannot know in advance whether to expect >> > these notifications. >> >> After reading it one more time, I'm not sure if I get it right in the >> first place. >> With this patch implementation, there is dpll change notification >> applied. >> By dpll notification I mean calling dpll_device_change_ntf function. >> Isn't it what you're looking for? >> Notification is triggered only in case when lock status has changed. >> It's unmanaged DPLL so the implementation is a little bit simplified, >> based on FW notification. >> There is no need for polling thread like it's done for E810. >> But even in case of E810, where polling is applied (2 samples per >> second), notification is triggered only in case of dpll/pin status >> change, not every 1 second. >> So please clarify, so either I don't understand the question (please >> note, I'm only covering the main author) or notification mechanism, at >> least about dpll lock state, is already implemented. >> > >Yes, device lock status change notification is definitely what we are >looking for, but there is more. Let me clarify the user perspective. >The e810-based telco system relies on both device and pin notifications. >Phase offset included in pin notifications is critical because the e810 >DPLL "Locked" state is too coarse for Telco requirements. >It is true that pin notifications are only sent on change; however, since >the phase offset varies slightly with every measurement, the driver detects >a change every second. This effectively turns the event-driven notification >into a periodic one. The e810-based application strongly relies on the fact >that phase offset notifications are unsolicited and the driver sends them >from time to time. >Now, with the unmanaged DPLL, no pin notification will be sent. Last time I >checked, the device and pin information looked like this: >Device: > {'clock-id': 1165870453030569040, > 'id': 4, > 'lock-status': 'locked', > 'mode': 'automatic', > 'mode-supported': ['automatic'], > 'module-name': 'ice', > 'type': 'eec'}, > >Input pin: >{ > "id": 17, > "module-name": "ice", > "clock-id": 1165870453030569040, > "board-label": "1588-TIME_SYNC", > "type": "ext", > "capabilities": [], > "frequency": 10
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
Hi Grzegors, Thanks very much for your reply! Added some clarifications inline. On Wed, Jan 7, 2026 at 11:33 PM Nitka, Grzegorz wrote: > > > -Original Message- > > From: Vitaly Grinberg > > Sent: Tuesday, December 16, 2025 3:42 PM > > To: Nitka, Grzegorz > > Cc: Loktionov, Aleksandr ; Nguyen, > > Anthony L ; Kubalewski, Arkadiusz > > ; [email protected]; intel-wired- > > [email protected]; [email protected]; linux- > > [email protected]; [email protected]; > > [email protected]; Kitszel, Przemyslaw > > > > Subject: Re:[Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for > > unmanaged DPLL on E830 NIC > > > > Will a notification be provided when the lock is re-acquired? > > > > Hi Vitaly, thanks for your comments. > We discussed it offline already, but I think I need more clarifications. > > Regarding above question ... yes, 'lock' recovery shall be reported in the > same way. > Maybe the name of health status is a little bit misleading > (ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK), > However health_info struct contains the current lock status (either 'locked' > or 'unlocked'). Great, thanks for clarifying this! > > Another concern is the absence of periodical pin notifications. With the > > E810, > > users received the active pin notifications every 1 second. However, the > > unmanaged DPLL appears to lack this functionality. User implementations > > currently rely on these periodical notifications to derive the overall clock > > state, metrics and events from the phase offset. It seems that unmanaged > > DPLL users will be forced to support two distinct types of DPLLs: one that > > sends periodical pin notifications and one that does not. Crucially, this > > difference does not appear to be reflected in the device capabilities, > > meaning users cannot know in advance whether to expect these > > notifications. > > After reading it one more time, I'm not sure if I get it right in the first > place. > With this patch implementation, there is dpll change notification applied. > By dpll notification I mean calling dpll_device_change_ntf function. > Isn't it what you're looking for? > Notification is triggered only in case when lock status has changed. > It's unmanaged DPLL so the implementation is a little bit simplified, based > on FW notification. > There is no need for polling thread like it's done for E810. > But even in case of E810, where polling is applied (2 samples per second), > notification is triggered only in case of > dpll/pin status change, not every 1 second. > So please clarify, so either I don't understand the question (please note, > I'm only covering the main author) > or notification mechanism, at least about dpll lock state, is already > implemented. > Yes, device lock status change notification is definitely what we are looking for, but there is more. Let me clarify the user perspective. The e810-based telco system relies on both device and pin notifications. Phase offset included in pin notifications is critical because the e810 DPLL "Locked" state is too coarse for Telco requirements. It is true that pin notifications are only sent on change; however, since the phase offset varies slightly with every measurement, the driver detects a change every second. This effectively turns the event-driven notification into a periodic one. The e810-based application strongly relies on the fact that phase offset notifications are unsolicited and the driver sends them from time to time. Now, with the unmanaged DPLL, no pin notification will be sent. Last time I checked, the device and pin information looked like this: Device: {'clock-id': 1165870453030569040, 'id': 4, 'lock-status': 'locked', 'mode': 'automatic', 'mode-supported': ['automatic'], 'module-name': 'ice', 'type': 'eec'}, Input pin: { "id": 17, "module-name": "ice", "clock-id": 1165870453030569040, "board-label": "1588-TIME_SYNC", "type": "ext", "capabilities": [], "frequency": 1000, "phase-adjust-min": 0, "phase-adjust-max": 0, "parent-device": [ { "parent-id": 4, "state": "connected", "direction": "input" } ] } I see a few challenges for the user here. The biggest one is that the application can't tell the difference between a device that will report phase offsets and this unmanaged device that never
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
> -Original Message- > From: Vitaly Grinberg > Sent: Tuesday, December 16, 2025 3:42 PM > To: Nitka, Grzegorz > Cc: Loktionov, Aleksandr ; Nguyen, > Anthony L ; Kubalewski, Arkadiusz > ; [email protected]; intel-wired- > [email protected]; [email protected]; linux- > [email protected]; [email protected]; > [email protected]; Kitszel, Przemyslaw > > Subject: Re:[Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for > unmanaged DPLL on E830 NIC > > Will a notification be provided when the lock is re-acquired? > Hi Vitaly, thanks for your comments. We discussed it offline already, but I think I need more clarifications. Regarding above question ... yes, 'lock' recovery shall be reported in the same way. Maybe the name of health status is a little bit misleading (ICE_AQC_HEALTH_STATUS_INFO_LOSS_OF_LOCK), However health_info struct contains the current lock status (either 'locked' or 'unlocked'). > Another concern is the absence of periodical pin notifications. With the E810, > users received the active pin notifications every 1 second. However, the > unmanaged DPLL appears to lack this functionality. User implementations > currently rely on these periodical notifications to derive the overall clock > state, metrics and events from the phase offset. It seems that unmanaged > DPLL users will be forced to support two distinct types of DPLLs: one that > sends periodical pin notifications and one that does not. Crucially, this > difference does not appear to be reflected in the device capabilities, > meaning users cannot know in advance whether to expect these > notifications. After reading it one more time, I'm not sure if I get it right in the first place. With this patch implementation, there is dpll change notification applied. By dpll notification I mean calling dpll_device_change_ntf function. Isn't it what you're looking for? Notification is triggered only in case when lock status has changed. It's unmanaged DPLL so the implementation is a little bit simplified, based on FW notification. There is no need for polling thread like it's done for E810. But even in case of E810, where polling is applied (2 samples per second), notification is triggered only in case of dpll/pin status change, not every 1 second. So please clarify, so either I don't understand the question (please note, I'm only covering the main author) or notification mechanism, at least about dpll lock state, is already implemented.
Re: [Intel-wired-lan] [PATCH v5 iwl-next] ice: add support for unmanaged DPLL on E830 NIC
Will a notification be provided when the lock is re-acquired? Another concern is the absence of periodical pin notifications. With the E810, users received the active pin notifications every 1 second. However, the unmanaged DPLL appears to lack this functionality. User implementations currently rely on these periodical notifications to derive the overall clock state, metrics and events from the phase offset. It seems that unmanaged DPLL users will be forced to support two distinct types of DPLLs: one that sends periodical pin notifications and one that does not. Crucially, this difference does not appear to be reflected in the device capabilities, meaning users cannot know in advance whether to expect these notifications.
