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 0E712C433EF for ; Sun, 26 Jun 2022 19:28:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231830AbiFZT2j (ORCPT ); Sun, 26 Jun 2022 15:28:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230490AbiFZT2i (ORCPT ); Sun, 26 Jun 2022 15:28:38 -0400 Received: from novek.ru (unknown [213.148.174.62]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B304E84 for ; Sun, 26 Jun 2022 12:28:37 -0700 (PDT) Received: from [192.168.0.18] (unknown [37.228.234.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by novek.ru (Postfix) with ESMTPSA id 8ED2B50060D; Sun, 26 Jun 2022 22:27:00 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 novek.ru 8ED2B50060D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=novek.ru; s=mail; t=1656271622; bh=8pu2A2mtA7LPXNAGljyZ3Pbl943STnrlxloqGfoUYCM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qws7U899HBLH1yUBtDvBqh9bhMnxx4X68RkcDLHhC+Q23xxCSxj05FJR0ZljhDA0B 76r1ConLRwlA6beaxzilnOsUi/vZIu/RgGGPaMTt1DXssW60JHAE9JEC5aeubawdoJ NeIKMkiePQZE4wWx7YbvyOJ+83abBLKI3bxV1Hwg= Message-ID: <9d59df64-588c-ef03-e978-89d03d29e0e4@novek.ru> Date: Sun, 26 Jun 2022 20:28:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [RFC PATCH v1 3/3] ptp_ocp: implement DPLL ops Content-Language: en-US To: Jonathan Lemon Cc: Jakub Kicinski , Vadim Fedorenko , Aya Levin , Arkadiusz Kubalewski , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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> From: Vadim Fedorenko In-Reply-To: <20220623233620.vq7oqzop6lg4nmlb@bsd-mbp.dhcp.thefacebook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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? 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 CC5E1C43334 for ; Sun, 26 Jun 2022 19:29:35 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HgzAFewBlHYK9ETJSLv7U57W8F+jMhSgVF8tACsI2Pk=; b=1oN2GZcaUxhaZM bDNAutAJ3lVKlX2PcL08pqC5aKzDrD229/6N1JSSYSLruCo1jjFvlLkKjKYQyTsb8brIFW/5m8LfZ ya59GDx6qq1gsivDhcfJSG40S5ZWMlDXYv4F9Fb7sbxl63EmtbtodP97qh6cuXb9KCtmJeyzobMmu LSJpjAzeFPIfa4tid3fKHo1iXUwLuDEEtq83+6nwKtVC1N80jUj5PmqvP3CIixj4mbnoi56pCxRvT d5BGvRWP7McddRF+pCACS9KqYny4oZLvcIxf24Z7nrLd6w0SlE7Sej234sJ85jwstBfi4cmKDninS +xGDvXk8WvYMZLnOydQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o5Xw0-00DF7M-Kj; Sun, 26 Jun 2022 19:28:40 +0000 Received: from [213.148.174.62] (helo=novek.ru) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o5Xvx-00DF64-K7 for linux-arm-kernel@lists.infradead.org; Sun, 26 Jun 2022 19:28:39 +0000 Received: from [192.168.0.18] (unknown [37.228.234.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by novek.ru (Postfix) with ESMTPSA id 8ED2B50060D; Sun, 26 Jun 2022 22:27:00 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 novek.ru 8ED2B50060D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=novek.ru; s=mail; t=1656271622; bh=8pu2A2mtA7LPXNAGljyZ3Pbl943STnrlxloqGfoUYCM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qws7U899HBLH1yUBtDvBqh9bhMnxx4X68RkcDLHhC+Q23xxCSxj05FJR0ZljhDA0B 76r1ConLRwlA6beaxzilnOsUi/vZIu/RgGGPaMTt1DXssW60JHAE9JEC5aeubawdoJ NeIKMkiePQZE4wWx7YbvyOJ+83abBLKI3bxV1Hwg= Message-ID: <9d59df64-588c-ef03-e978-89d03d29e0e4@novek.ru> Date: Sun, 26 Jun 2022 20:28:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [RFC PATCH v1 3/3] ptp_ocp: implement DPLL ops Content-Language: en-US To: Jonathan Lemon Cc: Jakub Kicinski , Vadim Fedorenko , Aya Levin , Arkadiusz Kubalewski , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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> From: Vadim Fedorenko In-Reply-To: <20220623233620.vq7oqzop6lg4nmlb@bsd-mbp.dhcp.thefacebook.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220626_122837_891132_9EE22045 X-CRM114-Status: GOOD ( 19.65 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel