Thread (22 messages) 22 messages, 5 authors, 2022-06-30

Re: [RFC PATCH v1 3/3] ptp_ocp: implement DPLL ops

From: Vadim Fedorenko <hidden>
Date: 2022-06-27 22:07:51
Also in: linux-arm-kernel

On 27.06.2022 20:27, Jonathan Lemon wrote:
On Sun, Jun 26, 2022 at 08:28:34PM +0100, Vadim Fedorenko wrote:
quoted
On 24.06.2022 00:36, Jonathan Lemon wrote:
quoted
On Fri, Jun 24, 2022 at 12:11:43AM +0100, Vadim Fedorenko wrote:
quoted
On 23.06.2022 19:28, Jonathan Lemon wrote:
quoted
On Thu, Jun 23, 2022 at 03:57:17AM +0300, Vadim Fedorenko wrote:
quoted
From: Vadim Fedorenko <redacted>
+static int ptp_ocp_dpll_get_source_type(struct dpll_device *dpll, int sma)
+{
+	struct ptp_ocp *bp = (struct ptp_ocp *)dpll_priv(dpll);
+	int ret;
+
+	if (bp->sma[sma].mode != SMA_MODE_IN)
+		return -1;
+
+	switch (ptp_ocp_sma_get(bp, sma)) {
+	case 0:
+		ret = DPLL_TYPE_EXT_10MHZ;
+		break;
+	case 1:
+	case 2:
+		ret = DPLL_TYPE_EXT_1PPS;
+		break;
+	default:
+		ret = DPLL_TYPE_INT_OSCILLATOR;
+	}
+
+	return ret;
+}
These case statements switch on private bits.  This needs to match
on the selector name instead.
Not sure that string comparison is a good idea. Maybe it's better to extend
struct ocp_selector with netlink type id and fill it according to hardware?
Sure, that could be an option.  But, as this is DPLL only, how does it
handle things when a pin is used for non-clock IO?  In the timecard,
for example, we have the frequency counters for input, and the frequency
generators/VCC/GND for output.

Actually our HW has a multi-level input, where the DPLL selects its
source from an internal mux - this isn't reflected here.  The external
pins feed into some complex HW logic, which performs its own priority
calculations before presenting the end result as an available selection
for the DPLL.
I don't really know how to deal with such configuration. For now I simply added
CUSTOM type but I'm not sure how to deal it 'set' functions. Do you have any
suggestions?
No suggestions other than the API should be able to handle things?
Ok, I will try to combine this with Arkadiusz's suggestion with priorities.
Also, should there be a notifier if the source changes?
Definitely. I'm working on *set operations and will add notifiers at the same time.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help