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 BA140C5479D for ; Wed, 11 Jan 2023 15:06:03 +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=7Y5BGaovYg1AVQr7r34TgquRfQMYrS1NM9USw7nThFI=; b=1sr4trCoh2UbrM gnczDyLQY7/z0L+1dWQDOuUBS8ekg04xiirEX+NuIAtGnQwWTI4l6E2pPqTuPkOlctVIgYxF6XG3X IrHHBV2Fpf1wdRk9e2q/kZ1TEWZ7USZy89N0JwKoYiFrDJ38MkQkTXYlI/vuKfpPNG8k9+qeh1EZS AnVt2cGItUF9qz9yM889utIKEWwf1VtKS3yX4S44vBJBOY83+EcCUXB8RYlujdvOM+VrWyIUB8+oQ sGRwiF7JXSdHv3R5XmcQV2hV9+b8DI1pCpdPlFEJRyEV0jDdskqGdxFdczP70nC1ogt/UEBKp+abm zT/O2BAnQzb7KOotIyGQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFcew-00Bv5c-FG; Wed, 11 Jan 2023 15:04:58 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFces-00Bv3g-Af for linux-arm-kernel@lists.infradead.org; Wed, 11 Jan 2023 15:04:57 +0000 Received: by mail-ej1-x636.google.com with SMTP id hw16so25676416ejc.10 for ; Wed, 11 Jan 2023 07:04:53 -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=wSndVBDlN4JUzHCG4iLF5UhWZTMXbKyI15vPIo6KiSU=; b=WTmIT17URH/10jxaZkCFZ/Su0dMdGH7NE5GghquSvWPPwpJd+6ILKuWlyNMm4H395e xxxRl10u9LGTOQaXpIKBxLC/FDqshM9cN589y9hVEsHgEwYnPXHEwK6qVD8FG6hH+pvE wrAlS2DiweSE7pAwI7neVmyozpz2rRA6hxUwmw7ztiGv1D2Dv/asvYg19Fk6VHhGU5NV IxjGNcfhzCgvP/n0ENrWZ705Nu0rcm2BPJBsia+jXMN3hBjfkPPUGskM4RMbnoc1blBr Z3Ts5KMdNCbIMyjPXfmrcsGDEEca7L/7CLtupaHeINXXkQRtV2U4OiVaG38GK2j+1ExM i1Rg== 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=wSndVBDlN4JUzHCG4iLF5UhWZTMXbKyI15vPIo6KiSU=; b=RDVoVvF5Kn07Y4UZX2Wh0LcjZG5oUKWioo80hJ6Ru/vl/TUtec365iYBdrVlRMvav2 +p6AoM0gKZZHkvbnLpdcqHUp6f5sv0g/SHXK8AWUyJzGqEgAgyhyQds8KlU/RrU9jze9 8W30439cLYmBnrhH56LARSF9vnC2tJ2g1Xt1wsHMIppt8isO2feRvfstdNDhDnK8SO01 XkR+BK0KwYf+6qmQK+LYiK+D7Qs/C3nV0KJRuPVPGsV9rIWcSVpphy2Wo7oSo1OqFT2Z f7E6w7GzZddkJdgaQBCoxh7PUKA5fOtqjAnYLm7bFW5FZSn6pBVCeoGXWYWWjgcICYxL CdrA== X-Gm-Message-State: AFqh2kr6rDA7ayqWmja34EDRib9Cu89ozi1VbcFdWgN+QmpJZHic6Wux 8s9xqDYtMGPUFE9a0oGnjvMdnA== X-Google-Smtp-Source: AMrXdXsAzLI1Zlu5S4eptp/SXJsEAFI0xjbkUEdexBFitl92UPyIF9Z09CaOEcx6v3MsIYc8oMHD7w== X-Received: by 2002:a17:906:184a:b0:78d:f456:1ed0 with SMTP id w10-20020a170906184a00b0078df4561ed0mr70252597eje.33.1673449491869; Wed, 11 Jan 2023 07:04:51 -0800 (PST) Received: from localhost ([217.111.27.204]) by smtp.gmail.com with ESMTPSA id ka13-20020a170907990d00b0073c10031dc9sm6196545ejc.80.2023.01.11.07.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jan 2023 07:04:50 -0800 (PST) Date: Wed, 11 Jan 2023 16:04: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: <20221207152157.6185b52b@kernel.org> <6e252f6d-283e-7138-164f-092709bc1292@machnikowski.net> <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-20230111_070454_578859_7E719793 X-CRM114-Status: GOOD ( 13.95 ) 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 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? >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? > >BR, >Arkadiusz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel