From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 34F3B215075 for ; Tue, 9 Jun 2026 10:25:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781000716; cv=none; b=nytXVBMYONsBz3MixmKQkjB+Qj/I/E7RGv9bkZHpC/QqF52EraW7pO+Vx7kQTekvcRCN+3l0y20tT9Vk3Qb7Nin49GEeOsAaFhwZhvYxphXXD2XQWoA7KNKGXKwsheJovaLNMyC9nGUQQExFUYRWYKEqP9xSpQQCWh1U6lK0npQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781000716; c=relaxed/simple; bh=HmV9PN+Xoys8KUjTyWPoNDvsxkzG/AwM6lFM1ni+rro=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lbG3uaWzHO8Ej60HTHVDT/qCYMsvGcH/m1dIfPh/BVLy/UPzHzpoCG4kFr+erZUGG4OJZ8TOfioYsO17SgAqCz/5hJfp9TU4mvtwf9NAwCaeP/G6WUBE8oCM6+Ox/QlU2hN4RSzMZks8swxHqfgCEBxQQMLRkl94udvvojAqLF4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=m3DTe6L8; arc=none smtp.client-ip=91.218.175.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="m3DTe6L8" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781000711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xHP9STYuApztcYR4EQHJ4/WZi2PkNPsO7JDes4+ASs0=; b=m3DTe6L86yPrOwJEWhjtjhyV29EI6PjmRc0MWFEYgHumMmqrp/uhz0IcqtFDNwpeS3Fa71 sQG0KPpRtqQtbnaXzlOqq+IHZY7IgjIrC0hViUMy+NbjWJwIyBzd+Pv3LRC9pFlW8NG6z9 28Y9eoAOCmvtYqd441U/HSG672y00FY= Date: Tue, 9 Jun 2026 11:24:47 +0100 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net-next v5 1/4] dpll: add DPLL_PIN_TYPE_INT_NCO pin type To: Ivan Vecera , Jakub Kicinski Cc: Arkadiusz Kubalewski , netdev@vger.kernel.org, Jiri Pirko , "David S. Miller" , Donald Hunter , Eric Dumazet , Jiri Pirko , Michal Schmidt , Paolo Abeni , Pasi Vaananen , Petr Oros , Prathosh Satish , Simon Horman , linux-kernel@vger.kernel.org, Grzegorz Nitka References: <20260531194423.383366-1-ivecera@redhat.com> <20260531194423.383366-2-ivecera@redhat.com> <20260603185037.05f8c6a0@kernel.org> <20260604081649.1ae5302d@kernel.org> <3c5e01f5-8563-41a3-964f-13fcb80383b7@redhat.com> <9b493ce2-6213-4a29-aeee-b473b6b16fa1@redhat.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Vadim Fedorenko In-Reply-To: <9b493ce2-6213-4a29-aeee-b473b6b16fa1@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 08/06/2026 16:30, Ivan Vecera wrote: > On 6/8/26 1:33 PM, Vadim Fedorenko wrote: >> On 04/06/2026 17:42, Ivan Vecera wrote: >>> On 6/4/26 5:16 PM, Jakub Kicinski wrote: >>>> On Thu, 4 Jun 2026 17:01:36 +0200 Ivan Vecera wrote: >>>>>> Purely going on intuition here but feels like NCO should be a mode >>>>>> (enum dpll_mode) rather than one of the input pins? >>>>>> >>>>>> More acks here would be great, Vadim, Arkadiusz, Grzegorz... ? >>>>> >>>>> I had a long discussion with Jiri about this and we agreed finally >>>>> that dpll_mode represents a reference (input pin) selection strategy >>>>> mode and not a DPLL device running mode. >>>> >>>> Long discussion? I see 2 emails ;) Let's hear from others. >>>> (thanks for the link BTW, _if_ there's a v6 please put it in the cover >>>> letter) >>> >>> I called him... he explained me 'why?' in detail. >>> I also appreciate others' opinion. >> >> Well, NCO mode means manual operation of frequency tuning. Does it mean >> that different tunings may be applied to different out pins of DPLL >> device? My assumption that it's not possible, and in this case NCO is >> property/mode of DPLL device rather than single pin. > > The NCO pin is only one per device... When it is connected, then the > device the pin is connected to is switched to NCO mode. In this mode > the device is not locked to any input reference and the driver allows > tuning of the DPLL frequency manually via PTP interface. > > Such tuning is applied only to output pins associated with this device > but not on others. > > Examples: > DPLL0 is driving output 0-3 and DPLL1 is driving output 4-7. > Then if you switch the DPLL0 to NCO mode (makes NCO pin connected to it) > then frequency tuning (via PTP) has only influence on output 0-3 (the > same tuning is applied). Outputs 4-7 are not touched as they are driven > by DPLL1 (that can be locked to some input reference). > > If you switch both DPLLs to NCO, then frequency tuning for DPLL0 affects > output 0-3 and tuning for DPLL1 output 4-7. Technically speaking you have described per-device behavior. And NCO pin can technically be virtual, just a configuration option via normal device communication channel. Doesn't feel like pin's attribute. Back in a days of DPLL RFC patches we have discussed the option with Arkadiusz, AFAIR we were leaning towards per-DPLL state for this case.