From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0DF7A3CB2D4 for ; Thu, 11 Jun 2026 12:09:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781179789; cv=none; b=c4rHor9PPTTxvW6F+xgR+P8C8Epx1Csy7TsAQxQLVmKPf9sVVi6dO6K0jB/dtaG16Hv4MtVwPe+tOSQdQSkqv4HkaeCFgYS4dvqvc0PWxNOb5a+R+lnvGOg/o6/S2OXkeiyD8MwrclRlMNZLLAUkk4bkj4f0mIkefWyRz6xhhcg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781179789; c=relaxed/simple; bh=ZjK56lQ40XRSCfovrLM16CvDySf903CFFII4+zH6ckI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sdDOm5O30siSPMId2wrIZ0Eljn2ui9AKP8PxrwD0u31JSUZlze03T/fKRy8FNPFwnMqV794QVVe3abw1wdQfMROXE9AV+Irrr1Htz7vjPIBOjHDkkw796XtQz/uhhuO5SMy5rzfFGep9CCERIfKd38ZWAQCqxdQtqkwyY1kwaN4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=resnulli.us; spf=none smtp.mailfrom=resnulli.us; dkim=pass (2048-bit key) header.d=resnulli-us.20251104.gappssmtp.com header.i=@resnulli-us.20251104.gappssmtp.com header.b=j+q4BITW; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=resnulli.us Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=resnulli.us Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=resnulli-us.20251104.gappssmtp.com header.i=@resnulli-us.20251104.gappssmtp.com header.b="j+q4BITW" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-490b3637b90so67572075e9.3 for ; Thu, 11 Jun 2026 05:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20251104.gappssmtp.com; s=20251104; t=1781179784; x=1781784584; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OgtDqbm68IM5KDrf7YAIfuu2gtjEHLe1UjPl7Bx4Kfs=; b=j+q4BITWzjb8AZQbtHkzqdkXr2ptzSogU8G0b/m2hr/NXI4xRJfW5b//NigFjLM7Yt B3CVLNA2j9+WtNaeR+iNUkirmtCD3T91YqWmSoyhUycvWAyhScbOg/qd3JA0GVDpNLn8 rIIn2PJO5rodhVEFRq4FlpUya5YTd2181p5Oiqcnl9b7acBCRHUSSJzVWOR0PyUXou6P r/zZDa/cJQNsdWA5r37tiTjdcNJ+2VkSMciqSHu7WKzfuUYbnuSwCVHOaMTTJ9yuuf1I iXypoumc2cYep9aXi+KAiFpDd7FLEhBXPeLI+YujKSUn+FAn2VAOjEktioxBjJcjbSo8 Q3bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781179784; x=1781784584; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OgtDqbm68IM5KDrf7YAIfuu2gtjEHLe1UjPl7Bx4Kfs=; b=lEb4j2QyVHreJ/urGOZvf8MCvLRewMvRK1xsdBWyDQojs5C0i6mVa/bXO2VyKnSnnZ DCdnScpbD5MtOtGt4LpK72d56IkK/ITvrDBxHMjQcWk94XH+kOo/DEbfMIdabi7oKHkE xDyZ93sRuTeHKBTmoxemqm4Bb23DOTA0jDp+DN8UogA+3bBZK9DgRYrkxue5KmuxgpfW GC09eigwrGVMv7EjN2RQ4tuQvswGBxv06XFWQh8rVK89MSvEuQ4AdRgPl4RBoBKDI9yQ 8sGw4Gpbjn9fF23caY/AWtC4yFZO5xIJrx4KpFvexjwr1ybJpmDvpEkhWtyyV8x+DSFM nF5w== X-Forwarded-Encrypted: i=1; AFNElJ/rm3L8v6ycdT6vwf0mm26GDwtmV0yX1v5wRvvXe0vnQzIwRMzI8bfkUQH+2EI1/MYiblvHDHbO3bzgYTg=@vger.kernel.org X-Gm-Message-State: AOJu0Yw81HXwtbylfJAa8A1J+80+20Lj5XRGAsckBBbHm0z3UyjhfzKG 9vrV3CdmzocTJfzn1IoDXXYvisXuqVGZbDfzPL2F+BFMLF5DRLR4sh3SCzKWTCtGVFg= X-Gm-Gg: Acq92OHJOdWddx92JQh+6n+t/3jSpARXKl/YShDnHLfXxtUCif+o0R1cohKozFfGWOm 7fbn9hIw1yV/kv3xXi+wthMvntTsshywx4wZ6amL+gyKT9Jnkl9ysHOSmRlpU77eRCnsKqctlwk tvZ6OChp2anJC24DL/oWzwPoXmgAGHmmNzZeOQBfo3md+eYSadFumKl2ifwe/juRGCOhrCdHqrT 8Vtn9yxjN10Rad0spIqXKLwLq6USnNh5ADpNG7w4DBbXcI5q5WTdOUlmeuO1TPJUWrmlVCpfHnw r9aZ4A/+HU4ZWkYfqGX7rhd6+PLh+gM5YuDBvwYe/HWGnDXhnr5fhtFfPmyJ3Xq1SewKIMc6DN5 9zgVY6PnwL+AaGBjtSrMi0ziWidiccyZa+FddpRPvIpHUNFq2rm2TJm8tpEvHt3JxNAXaOp2gLJ JYPat8cEWVOp29079Xk78fpcLvBZY6kLCuQipJmvGgLfE= X-Received: by 2002:a05:600c:8b25:b0:490:5e2a:f924 with SMTP id 5b1f17b1804b1-490e55b96b0mr35436165e9.7.1781179784256; Thu, 11 Jun 2026 05:09:44 -0700 (PDT) Received: from localhost ([140.209.217.212]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2f5612sm78603105f8f.15.2026.06.11.05.09.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2026 05:09:43 -0700 (PDT) Date: Thu, 11 Jun 2026 14:09:39 +0200 From: Jiri Pirko To: Ivan Vecera Cc: "Kubalewski, Arkadiusz" , "netdev@vger.kernel.org" , Jiri Pirko , "David S. Miller" , Donald Hunter , Eric Dumazet , Jakub Kicinski , "Schmidt, Michal" , Paolo Abeni , "Vaananen, Pasi" , "Oros, Petr" , Prathosh Satish , Simon Horman , Vadim Fedorenko , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH net-next v5 1/4] dpll: add DPLL_PIN_TYPE_INT_NCO pin type Message-ID: References: <20260531194423.383366-1-ivecera@redhat.com> <20260531194423.383366-2-ivecera@redhat.com> <99cebea4-156a-4379-922e-07c50f766fbe@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Wed, Jun 10, 2026 at 05:45:46PM +0200, ivecera@redhat.com wrote: >On 6/10/26 3:04 PM, Kubalewski, Arkadiusz wrote: >> > From: Ivan Vecera >> > Sent: Tuesday, June 9, 2026 4:59 PM >> > >> > On 6/9/26 4:00 PM, Kubalewski, Arkadiusz wrote: >> > > > From: Jiri Pirko >> > > > Sent: Tuesday, June 9, 2026 10:51 AM >> > > > >> > > > Mon, Jun 08, 2026 at 07:03:46PM +0200, arkadiusz.kubalewski@intel.com >> > > > wrote: >> > > > > > From: Ivan Vecera >> > > > > > Sent: Monday, June 8, 2026 5:48 PM >> > > > > > >> > > > > > On 6/8/26 4:43 PM, Kubalewski, Arkadiusz wrote: >> > > > > > > > From: Ivan Vecera >> > > > > > > > Sent: Sunday, May 31, 2026 9:44 PM ... >> > > > > > > > - >> > > > > > > > name: gnss >> > > > > > > > doc: GNSS recovered clock >> > > > > > > > + - >> > > > > > > > + name: int-nco >> > > > > > > > + doc: | >> > > > > > > > + Device internal numerically controlled oscillator. >> > > > > > > > + When connected as a DPLL input, the DPLL enters NCO mode >> > > > > > > > + where the output frequency is adjusted by the host via >> > > > > > > > + the PTP clock interface. >> > > > > > > >> > > > > > > Hi Ivan! >> > > > > > > >> > > > > > > How would you control this in case of automatic mode dpll? >> > > > > > > Automatic mode DPLL shall be controlled on HW level, such pin >> > > > > > > brakes that rule and requires some driver magic to show it is >> > > > > > > higher priority then the rest of the pins? >> > > > > > >> > > > > > The NCO pin can be connected only in manual mode. In other words a >> > > > > > DPLL in automatic mode cannot select NCO pin (switch to NCO mode) by >> > > > > > its own. >> > > > > > >> > > > > >> > > > > Being picky on DPLL_MODE for enabling feature is not something we >> > > > > can allow if it is not related to HW limitation, is it? >> > > > > Could you please elaborate why it is not possible for AUTOMATIC mode? >> > > > >> > > > In automatic mode, the pin selection logic is defined upon prio. I >> > > > can imagine that if NCO pin has the highest prio of the available >> > > > ones, it gets picked. I would be aligned 100% with automatic mode >> > > > behaviour. >> > > > Is there a real usecase for it? >> > > > >> > > > [..] >> > > >> > > This is not true. AUTOMATIC mode is HW solution, SW driver ONLY >> > > configures priorities on the inputs, not manages the active inputs. >> > > This brakes that behavior, the SW driver would have to manually >> > > override the AUTMATIC mode to be fed from such NCO pin as it doesn't >> > > exists on it's priority list, HW cannot pick or use it. >> > >> > Correct, AUTO mode is hardware feature and it should not be emulated by a >> > driver. If the hardware does not support it then the switching between >> > input references should be done by userspace (by monitoring ffo, >> > phase_offset, operstate). >> > >> >> Yes, exactly, so for AUTOMATIC mode HW it will not be possible to create >> such pin, which means that NCO pin would serve only a MANUAL mode >> implementation. >> Basically this is something we shall not allow to happen. DPLL API >> should be designed to cover the case where AUTO mode is able to implement >> all features consistently. > >If you don't like the proposal from Jiri (NCO switch driven by NCO pin >priority -> highest==enter_nco else leave_nco) then it could be possible >to handle the switching by allowing the state 'connected' in AUTO mode >for the NCO pin type. Then the implementation will be the same for both >selection modes. > >Only difference would be that a user does not need to switch the device >from the AUTO to MANUAL mode. > >> > > The real use case is that any DPLL can switch the mode to this one >> > > instead of implementing MANUAL mode just to use the feature with a >> > > 'virtual' pin. >> > >> > I don't expect this... but it is up to a driver. I don't plan such >> > functionality in zl3073x as the NCO pin does not expose prio_get() and >> > prio_set() callbacks - so it is clear that this pin cannot be part of the >> > automatic selection. >> > >> > Ivan >> >> There is a difference between particular HW and API capabilities, with the >> proposed API we would disallow the possibility of such implementation for >> existing HW variants. >> >> DPLL NCO MODE would allow that but as pointed here by Ivan and by Jiri in >> the other email it would also require the extra implementation for some >> configuration - device level phase/ffo handling. >> >> To summarize it all, I don't have such simple solution for it. >> >> First thing that comes to my mind is to combine both approaches. >> Make it possible for AUTMATIC mode to also set "CONNECTED" state >> on certain kind of "OVERRIDE" pins, where it could be determined by >> the type of PIN and embed that logic into the DPLL subsystem. > >The possible states for particual pins are now handled at a driver level >so the driver decides if the requested state is correct or not. So it >could be easy to implement this. > >For auto mode allowed states: >- input references: selectable / disconnected >- nco pin: connected / disconnected > >> Basically, if driver registers such NCO pin it would be always selected >> manually, and in such case all the other pins are going to disconnected >> state while DPLL mode is also a "OVERRIDE" or something like it. > >I would leave this decision on the driver level... Imagine the potential >HW that would allow to switch NCO mode if there is no valid input >reference. > >Example: > >REF0 (prio 0) -> +------+ -> OUT0 >REF1 (prio 1) -> | DPLL | -> ... >NCO (prio 2) -> +------+ -> OUTn > >Such HW would prefer REF0 or REF1 and lock to one of them if they are >qualified. But if they are NOT, then it switches to NCO mode. > >In this situation the relevant driver would allow to configure priority >and state 'selectable' for this NCO pin. > >> Perhaps the pin type could include OVERRIDE in it's name to make it less >> confusing and needs some extra documentation. >> >> Thoughts? >I think _INT_ is ok. In the case of TYPE_INT_OSCILLATOR it is also >obvious that it is not a standard input reference. > >Jiri, Vadim, Arek, thoughts? I agree with you, the driver should have the flexibility to implement this according to his/hw's needs/capabilities. If it implements prio selection in AUTO mode, let it have it. If it implements manual NCO pin selection in AUTO mode using connected/disconnected override, let it have it. Moreover, I actually like the "override" capability for pins in AUTO mode in general. It may be handy for other usecases as well.