intel/gnss enable disable #114
Conversation
lack
commented
Nov 27, 2025
lack
commented
- Expose a few more DPLL netlink constants
- addons/intel: Introduce gnss.disabled flag to disable e825 incoming GNSS for BC profiles
Signed-off-by: Jim Ramsay <[email protected]>
|
Thanks for your PR, |
lack
force-pushed
the
intel/gnss_enable_disable
branch
from
42e2d35 to
e718da0
Compare
|
Note: Not quite working yet - The "enable" seems to work great, but the "disable" gets a netlink error I don't yet understand. |
…NSS for BC profiles We accomplish this by enabling/disabling the state of all pins that are type gnss, enable setting state, and input direction. Signed-off-by: Jim Ramsay <[email protected]>
lack
force-pushed
the
intel/gnss_enable_disable
branch
from
e718da0 to
1d5413c
Compare
| DpllSettings map[string]uint64 `json:"settings"` | ||
| PhaseOffsetPins map[string]map[string]string `json:"phaseOffsetPins"` | ||
| PhaseInputs []PhaseInputs `json:"interconnections"` | ||
| Gnss GnssOptions `json:"gnss"` |
There was a problem hiding this comment.
Not sure you need this input. The PhaseInputs already contains this field here. This is later used in clockChain, err = InitClockChain(e825Opts, nodeProfile) on line 151. This function is needed to initialize the clock type to "T-BC", which is widely used in the code including the events proxy, but it is currently very E810-specific, and it needs adaptation. For example it calls InitPinsTBC that disables E810 GNSS, but this call is going to cause errors with Microchip, as the priority 255 is illegal and pin label is different.
Maybe we need to refactor InitClockChain to split away hardware-specific functionality... WDYT?
There was a problem hiding this comment.
I looked into that but:
- I thought a fresh switch specifically for e825-only without any of the phase-inputs baggage was a quicker path to the BC
- Also not as potentially destabilizing to existing e810 code (since we'd have to do some deeper refactoring of the clock chain logic to make it work with e825)
- Less "throw-away" code since apiv2 is going to do this better anyway!
There was a problem hiding this comment.
I looked into that but:
- I thought a fresh switch specifically for e825-only without any of the phase-inputs baggage was a quicker path to the BC
- Also not as potentially destabilizing to existing e810 code (since we'd have to do some deeper refactoring of the clock chain logic to make it work with e825)
- Less "throw-away" code since apiv2 is going to do this better anyway!
There was a problem hiding this comment.
I suppose I could use the existing flag but just go with a completely different implementation...
2 participants
