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 21817C46467 for ; Tue, 10 Jan 2023 20:06:51 +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:MIME-Version:References:In-Reply-To: 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=7ONwj5N2i71QR8rTALV/wmUt3ZZbzCidYHGL7NYp8xc=; b=OEFPSaagIC/sLJ cfTJpLSM+mUNNBir229IpBh0R2/Q1rofB+r7ZSZKeLKmrs19sXDRYGCTw8BuMY+D6JU2D3xX+Lsn5 jrHhbVgii/stmRyfYXILpNYfGbPlghGtMaKOhG4Fld2NQuSVL9SG7pmBqkuPHCOHxvczR8OFQacuo WwxUDqYPbPuNLVISSIVIxFAelVUzNM9oc1IcyKfSNql/IkKHZyDD5rDD7sNs/Eu2UbmRdu0nHGRbg wUjt4Gh4DOiqjQUqRK5STAnKVqm2BI59ncrIOnBdrQP0kaYD1CpUh477jGUmWZhKOn8Z3g6Se5g2v eUJYfqB0fBujeJQeAjHA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFKsg-008R4j-DC; Tue, 10 Jan 2023 20:05:58 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFKsd-008R3z-DF for linux-arm-kernel@lists.infradead.org; Tue, 10 Jan 2023 20:05:56 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id ACE6EB8197F; Tue, 10 Jan 2023 20:05:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBAE3C433EF; Tue, 10 Jan 2023 20:05:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673381151; bh=Vd0GZVeHo6JIhOHYGd6tKf+QIQ4pPMNDJBgviINx9fE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=o3eiLY3U8M8pGbVPR2U3WTwZagHMpVndZHKQPrnuRHRNxiGG0Ie9Usxn3wvM3m4Dc FsFY4HJrAYujIGOytwA18gM04V882HzdcHC34KF5ooDnT8Bl4JGb1rVBgg3CqqPKym egfFnUPTR7YUaSaRfpEgB8mZ9Rf71CIhD6j80fsgSHdHQM+khuwGR/KfsYNZ2WD8US avcxktNzqZPKtmedCdiOmwl5tF69wtQomwDcPmLY6W6dIs5J4OGnLbIQSUI+CReOXp XECbioWHgMI+ZB3PBi5p57fSPoaZJGaBJ3oS9yvBTDpULvmyIpepV8y+OzpYRix12w D0OkRDt/tnkGg== Date: Tue, 10 Jan 2023 12:05:49 -0800 From: Jakub Kicinski To: "Kubalewski, Arkadiusz" Cc: Jiri Pirko , 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: <20230110120549.4d764609@kernel.org> In-Reply-To: References: <20221206184740.28cb7627@kernel.org> <10bb01d90a45$77189060$6549b120$@gmail.com> <20221207152157.6185b52b@kernel.org> <6e252f6d-283e-7138-164f-092709bc1292@machnikowski.net> <20221209083104.2469ebd6@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230110_120555_648222_40B7CB3D X-CRM114-Status: GOOD ( 14.85 ) 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 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel