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 9426DC54EBD for ; Thu, 12 Jan 2023 14:45:26 +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=Az8InxYiQatU7JmgiHcmZKPkbLaiTcv9wgrDKU2gxLs=; b=jk1vV3b3GBUlVB a6S5PgkRW/My7y623XsB5JykDqG5rDr2OGMre/JIvjpeYE2d1GUaOpIiuWFN+cVGKEYFuEOlMP3xV 9HSwN1EEi2pSaLJGnfdBa40zqTng5bjgakwhdczYTo4KA2zCT4VeBCTUohH/veoG/rhp88Q6MiZWh s88EmT7pJomKYKwrppLgXXmtN/sQkJw/Swc5FTwAUOV6tEBldmVuEKl//PpoSvjjAf84jRlR2dLxT dIy7WblsfbSYl783P1fhiracBGjMfm2mGcvYdb6cnv9xr8ipyCM/5g8WX/XFX1jfI2fL1Dqzd16eF ZTrF8t3YwDIFKsbVQHQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFyoC-00FRHY-KX; Thu, 12 Jan 2023 14:44:00 +0000 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFyo6-00FREW-OD for linux-arm-kernel@lists.infradead.org; Thu, 12 Jan 2023 14:43:58 +0000 Received: by mail-ej1-x629.google.com with SMTP id u19so45236389ejm.8 for ; Thu, 12 Jan 2023 06:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; 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=FZ+8HHMtBhm4FR1fBsHJK63o1abNxUgWSrPVOH5d3iw=; b=DoEmtYJQGonS61K6saGJQpRl1ps1UfR3y5aUXY6FfjIuBPpg10sTz5IL/L+f7Y5WA3 u5zRK4mXI+VlhEKi+TdT4y7oXIlmlYsr5CR4MuXxXZUdOnD1ViU8hO2cAZI4pbHI7YLj PcnGtOnl5yjFVe8RaH7/0P4TNYwd/3NsgAzoyCY3o/jbNlRF+h5EIvwyMmnSpsriQFwY Lvzw/uVQ5/RAzTuhO3mUlCzIipfpSz1qUuKLhdM6FW4od80MkKs2f+FFaoeBqFuNDa9O 4z7BkA43AVFb+qGHkzK9kZqkqnWI3lkKj8bnjA3tchIVx2U/prFNRvA8VtLgLjtIpt/D TBUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FZ+8HHMtBhm4FR1fBsHJK63o1abNxUgWSrPVOH5d3iw=; b=EpEuZXUioVbqepeqKO4/iVrrn56ezXwpdJsBDqT5h9sRgGDXUvGulqLV3++bR4IYBf Uo7phLh7DGP4OOeHhbARKV0QgDMiPVo+X1U+dIzYUO1BCfoWq3OT09ZcJV/STzd+4msW r6Rj/i7HdiXfcDwMcUmMhtlwOMLtbVPxz1K0nmdv+LEcz+Z0Nbr0FBN4rmTNBkVYDWd1 Ma1AuVbjdJ+k23QEt+lOlLvlmuOcVmZarmANd4iQUAKhRpMMcuwBdiWM3Pil3DLC9OoU KbnQbb//lbS5BAczoZvS2p7u6fzn9aH6N1sVMV+5uxmX3Xeq1qUeTYddYXdby4r55s2P r6Yw== X-Gm-Message-State: AFqh2krYOAWstUg4xwddSpW/YAEPEDE2Q45RqG8N1PUVl5eZdsO2MNht OYPXprCwPO8IqGn15hQb0J2HTw== X-Google-Smtp-Source: AMrXdXvhGyAFE70MT9iQZf8X8kJsSReLM9h1cNphTO+3C0L/b7eEXI+p2GJzuQKFcutM1uXXNfP1EA== X-Received: by 2002:a17:907:d48a:b0:7c1:766e:e09 with SMTP id vj10-20020a170907d48a00b007c1766e0e09mr70504227ejc.29.1673534631462; Thu, 12 Jan 2023 06:43:51 -0800 (PST) Received: from localhost ([217.111.27.204]) by smtp.gmail.com with ESMTPSA id y11-20020aa7c24b000000b004954c90c94bsm7290057edo.6.2023.01.12.06.43.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Jan 2023 06:43:50 -0800 (PST) Date: Thu, 12 Jan 2023 15:43:49 +0100 From: Jiri Pirko To: "Kubalewski, Arkadiusz" Cc: Jakub Kicinski , Maciek Machnikowski , 'Vadim Fedorenko' , 'Jonathan Lemon' , 'Paolo Abeni' , "netdev@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-clk@vger.kernel.org" Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Message-ID: References: <20221209083104.2469ebd6@kernel.org> <20230110120549.4d764609@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230112_064355_036741_93E636F3 X-CRM114-Status: GOOD ( 20.05 ) 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 Thu, Jan 12, 2023 at 01:15:30PM CET, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko >>Sent: Wednesday, January 11, 2023 5:15 PM >>To: Kubalewski, Arkadiusz >> >>Wed, Jan 11, 2023 at 04:30:44PM CET, arkadiusz.kubalewski@intel.com wrote: >>>>From: Jiri Pirko >>>>Sent: Wednesday, January 11, 2023 4:05 PM >>>>To: Kubalewski, Arkadiusz >>>> >>>>Wed, Jan 11, 2023 at 03:16:59PM CET, arkadiusz.kubalewski@intel.com >>wrote: >>>>>>From: Jiri Pirko >>>>>>Sent: Wednesday, January 11, 2023 9:20 AM >>>>>> >>>>>>Tue, Jan 10, 2023 at 09:05:49PM CET, kuba@kernel.org wrote: >>>>>>>On Mon, 9 Jan 2023 14:43:01 +0000 Kubalewski, Arkadiusz wrote: >>>>>>>> This is a simplified network switch board example. >>>>>>>> It has 2 synchronization channels, where each channel: >>>>>>>> - provides clk to 8 PHYs driven by separated MAC chips, >>>>>>>> - controls 2 DPLLs. >>>>>>>> >>>>>>>> Basically only given FW has control over its PHYs, so also a control >>>>>>over it's >>>>>>>> MUX inputs. >>>>>>>> All external sources are shared between the channels. >>>>>>>> >>>>>>>> This is why we believe it is not best idea to enclose multiple DPLLs >>>>>>with one >>>>>>>> object: >>>>>>>> - sources are shared even if DPLLs are not a single synchronizer >>chip, >>>>>>>> - control over specific MUX type input shall be controllable from >>>>>>different >>>>>>>> driver/firmware instances. >>>>>>>> >>>>>>>> As we know the proposal of having multiple DPLLs in one object was a >>>>try >>>>>>to >>>>>>>> simplify currently implemented shared pins. We fully support idea of >>>>>>having >>>>>>>> interfaces as simple as possible, but at the same time they shall be >>>>>>flexible >>>>>>>> enough to serve many use cases. >>>>>>> >>>>>>>I must be missing context from other discussions but what is this >>>>>>>proposal trying to solve? Well implemented shared pins is all we need. >>>>>> >>>>>>There is an entity containing the pins. The synchronizer chip. One >>>>>>synchronizer chip contains 1-n DPLLs. The source pins are connected >>>>>>to each DPLL (usually). What we missed in the original model was the >>>>>>synchronizer entity. If we have it, we don't need any notion of somehow >>>>>>floating pins as independent entities being attached to one or many >>>>>>DPLL refcounted, etc. The synchronizer device holds them in >>>>>>straightforward way. >>>>>> >>>>>>Example of a synchronizer chip: >>>>>>https://www.renesas.com/us/en/products/clocks-timing/jitter- >>attenuators- >>>>>>frequency-translation/8a34044-multichannel-dpll-dco-four-eight- >>>>>>channels#overview >>>>> >>>>>Not really, as explained above, multiple separated synchronizer chips >>can >>>>be >>>>>connected to the same external sources. >>>>>This is why I wrote this email, to better explain need for references >>>>between >>>>>DPLLs and shared pins. >>>>>Synchronizer chip object with multiple DPLLs would have sense if the >>pins >>>>would >>>>>only belong to that single chip, but this is not true. >>>> >>>>I don't understand how it is physically possible that 2 pins belong to 2 >>>>chips. Could you draw this to me? >>>> >>> >>>Well, sure, I was hoping this is clear, without extra connections on the >>draw: >> >>Okay, now I understand. It is not a shared pin but shared source for 2 >>pins. >> > >Yes, exactly. > >> >>>+----------+ >>>|i0 - GPS |--------------\ >>>+----------+ | >>>+----------+ | >>>|i1 - SMA1 |------------\ | >>>+----------+ | | >>>+----------+ | | >>>|i2 - SMA2 |----------\ | | >>>+----------+ | | | >>> | | | >>>+---------------------|-|-|-------------------------------------------+ >>>| Channel A / FW0 | | | +-------------+ +---+ +--------+ | >>>| | | |-i0--|Synchronizer0|---| |---| PHY0.0 |--| >> >>One pin here ^^^ >> >>>| +---+ | | | | | | | +--------+ | >>>| PHY0.0--| | | |---i1--| |---| M |---| PHY0.1 |--| >>>| | | | | | | +-----+ | | A | +--------+ | >>>| PHY0.1--| M | |-----i2--| |DPLL0| | | C |---| PHY0.2 |--| >>>| | U | | | | | +-----+ | | 0 | +--------+ | >>>| PHY0.2--| X |--+----------i3--| +-----+ |---| |---| ... |--| >>>| | 0 | | | | | | |DPLL1| | | | +--------+ | >>>| ... --| | | /--------i4--| +-----+ |---| |---| PHY0.7 |--| >>>| | | | | | | | +-------------+ +---+ +--------+ | >>>| PHY0.7--| | | | | | | | >>>| +---+ | | | | | | >>>+----------------|-|--|-|-|-------------------------------------------+ >>>| Channel B / FW1| | | | | +-------------+ +---+ +--------+ | >>>| | | | | \-i0--|Synchronizer1|---| |---| PHY1.0 |--| >> >>And second pin here ^^^ >> >>There are 2 separate pins. Sure, they need to have the same config as >>they are connected to the same external entity (GPS, SMA1, SMA2). >> >>Perhaps we need to have a board description using dts to draw this >>picture so the drivers can use this schema in order to properly >>configure this? >> >>My point is, you are trying to hardcode the board geometry in the >>driver. Is that correct? >> > >Well, we are trying to have userspace-friendly interface :) >As we discussed yesterday dts is more of embedded world thing and we don't >want to go that far, the driver knows the hardware it is using, thus it >shall be enough if it has all the information needed for initialization. >At least that is what I understood. Yes, I think yesterday called cleared things up. Thanks! > >BR, >Arkadiusz > >> >>>| +---+ | | | | | | | | +--------+ | >>>| PHY1.0--| | | | | \---i1--| |---| M |---| PHY1.1 |--| >>>| | | | | | | +-----+ | | A | +--------+ | >>>| PHY1.1--| M | | | \-----i2--| |DPLL0| | | C |---| PHY1.2 |--| >>>| | U | | | | +-----+ | | 1 | +--------+ | >>>| PHY1.2--| X | \-|--------i3--| +-----+ |---| |---| ... |--| >>>| | 1 | | | |DPLL1| | | | +--------+ | >>>| ... --| |----+--------i4--| +-----+ |---| |---| PHY1.7 |--| >>>| | | +-------------+ +---+ +--------+ | >>>| PHY1.7--| | | >>>| +---+ | >>>+---------------------------------------------------------------------+ >>> >>>> >>>>>As the pins are shared between multiple DPLLs (both inside 1 integrated >>>>circuit >>>>>and between multiple integrated circuits), all of them shall have >>current >>>>state >>>>>of the source or output. >>>>>Pins still need to be shared same as they would be inside of one >>>>synchronizer >>>>>chip. >>>> >>>>Do I understand correctly that you connect one synchronizer output to >>>>the input of the second synchronizer chip? >>> >>>No, I don't recall such use case. At least nothing that needs to exposed >>>in the DPLL subsystem itself. >>> >>>BR, >>>Arkadiusz >>> >>>> >>>>> >>>>>BR, >>>>>Arkadiusz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel