From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3420C433EF for ; Mon, 27 Jun 2022 19:28:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240439AbiF0T2J (ORCPT ); Mon, 27 Jun 2022 15:28:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240433AbiF0T2C (ORCPT ); Mon, 27 Jun 2022 15:28:02 -0400 Received: from smtp5.emailarray.com (smtp5.emailarray.com [65.39.216.39]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E36D6582 for ; Mon, 27 Jun 2022 12:27:55 -0700 (PDT) Received: (qmail 48032 invoked by uid 89); 27 Jun 2022 19:27:54 -0000 Received: from unknown (HELO localhost) (amxlbW9uQGZsdWdzdmFtcC5jb21AMTYzLjExNC4xMzIuNQ==) (POLARISLOCAL) by smtp5.emailarray.com with SMTP; 27 Jun 2022 19:27:54 -0000 Date: Mon, 27 Jun 2022 12:27:52 -0700 From: Jonathan Lemon To: Vadim Fedorenko Cc: Jakub Kicinski , Vadim Fedorenko , Aya Levin , Arkadiusz Kubalewski , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH v1 3/3] ptp_ocp: implement DPLL ops Message-ID: <20220627192752.ruo4n7imxqch75qg@bsd-mbp.dhcp.thefacebook.com> References: <20220623005717.31040-1-vfedorenko@novek.ru> <20220623005717.31040-4-vfedorenko@novek.ru> <20220623182813.safjhwvu67i4vu3b@bsd-mbp.dhcp.thefacebook.com> <20220623233620.vq7oqzop6lg4nmlb@bsd-mbp.dhcp.thefacebook.com> <9d59df64-588c-ef03-e978-89d03d29e0e4@novek.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9d59df64-588c-ef03-e978-89d03d29e0e4@novek.ru> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Jun 26, 2022 at 08:28:34PM +0100, Vadim Fedorenko wrote: > On 24.06.2022 00:36, Jonathan Lemon wrote: > > On Fri, Jun 24, 2022 at 12:11:43AM +0100, Vadim Fedorenko wrote: > > > On 23.06.2022 19:28, Jonathan Lemon wrote: > > > > On Thu, Jun 23, 2022 at 03:57:17AM +0300, Vadim Fedorenko wrote: > > > > > From: Vadim Fedorenko > > > > > +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? Also, should there be a notifier if the source changes? -- Jonathan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D928FC43334 for ; Mon, 27 Jun 2022 19:29:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ls5lyC1TCxSakeAv8+wavhBxC7RNv5CvFaDa0j3mN0U=; b=v3bNcmRzsIhwhA Br21sl+rH8KzlWspyyKP2m2Ti32K4OfvUVuz4az71QumXHu6A8Us03hWtx+TUrGn4Z9Xn8XEET2s5 /g5IGHlXhqwUhUVXtt7CvPZXk0i26zfjAClxpkF8YoTyhoe2vO9EFlxXNs8NeIRdbs0gZcQF6bIBV 2G2XtOKUfANxrIPYj5Ac+9eLrxXkZ/DRTkKBvNmAy9g4TrTS7x8Bapgin+JIDQWFwuepY2HpxMOnD lveFsE4npAAMPb3Odyosk+KMHKQlSicLMKu3FU2eMjjiwPdQ7DDJiaBEqWOnVCB2hXp5XgVIjqb17 hXZ2HEYSu7BWRgQ63PMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o5uOu-002Xq4-CB; Mon, 27 Jun 2022 19:28:00 +0000 Received: from smtp5.emailarray.com ([65.39.216.39]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o5uOr-002Xpe-4E for linux-arm-kernel@lists.infradead.org; Mon, 27 Jun 2022 19:27:58 +0000 Received: (qmail 48032 invoked by uid 89); 27 Jun 2022 19:27:54 -0000 Received: from unknown (HELO localhost) (amxlbW9uQGZsdWdzdmFtcC5jb21AMTYzLjExNC4xMzIuNQ==) (POLARISLOCAL) by smtp5.emailarray.com with SMTP; 27 Jun 2022 19:27:54 -0000 Date: Mon, 27 Jun 2022 12:27:52 -0700 From: Jonathan Lemon To: Vadim Fedorenko Cc: Jakub Kicinski , Vadim Fedorenko , Aya Levin , Arkadiusz Kubalewski , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH v1 3/3] ptp_ocp: implement DPLL ops Message-ID: <20220627192752.ruo4n7imxqch75qg@bsd-mbp.dhcp.thefacebook.com> References: <20220623005717.31040-1-vfedorenko@novek.ru> <20220623005717.31040-4-vfedorenko@novek.ru> <20220623182813.safjhwvu67i4vu3b@bsd-mbp.dhcp.thefacebook.com> <20220623233620.vq7oqzop6lg4nmlb@bsd-mbp.dhcp.thefacebook.com> <9d59df64-588c-ef03-e978-89d03d29e0e4@novek.ru> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9d59df64-588c-ef03-e978-89d03d29e0e4@novek.ru> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220627_122757_345739_65D81FB2 X-CRM114-Status: GOOD ( 25.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Jun 26, 2022 at 08:28:34PM +0100, Vadim Fedorenko wrote: > On 24.06.2022 00:36, Jonathan Lemon wrote: > > On Fri, Jun 24, 2022 at 12:11:43AM +0100, Vadim Fedorenko wrote: > > > On 23.06.2022 19:28, Jonathan Lemon wrote: > > > > On Thu, Jun 23, 2022 at 03:57:17AM +0300, Vadim Fedorenko wrote: > > > > > From: Vadim Fedorenko > > > > > +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? Also, should there be a notifier if the source changes? -- Jonathan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel