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 06541C46467 for ; Wed, 11 Jan 2023 16:15:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233480AbjAKQPD (ORCPT ); Wed, 11 Jan 2023 11:15:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56202 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232735AbjAKQPA (ORCPT ); Wed, 11 Jan 2023 11:15:00 -0500 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97FA365AE for ; Wed, 11 Jan 2023 08:14:58 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id gh17so38140865ejb.6 for ; Wed, 11 Jan 2023 08:14:58 -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=ZVgO94N/nb0C0chpJhGPxGhX0WKBJe9OSAqLZGN9MPA=; b=TVjIDl188h/cYo2yMId+ghWA1ae7nHMzsfPHhLnY2daGFnW+b3e89R33GuP68rIeAp j3TrKsoUXI4EuEGn3fI+WMO8VFRKMv7OrandqlXq0GxysjHRZ4YcKEcBHbNaiYwtVxFj HVYSg1LD09vSiAgZs/q9kyX1KvJu26kqlxNalwrN6H67diFhZ4MK8SYrmv9ayntnVYNM sk1UEabg3VPMK5+V8GQ0vHbaPhCFQR3hoJJi2xn/936eL3oCvvidmJUp3FA0tJjTMdfJ Pyke+8+TjLrhQU74BqiFcwLqS4N62KEbquTszcNAFDZsv25/gTrBFJRmV8TyE20mHq19 e/ow== 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=ZVgO94N/nb0C0chpJhGPxGhX0WKBJe9OSAqLZGN9MPA=; b=NDSEYvVM7rT6caJWeBjDQuh+WhghCloCsSeMFugKCDb8/hgCkaqEQjxuHl82ME6nA1 BQlmwT7RtfU7R32QDJ7+axBaS8hq4ChYAMVyKhIJq5FL733lZkcqu7qWdvSOIbpvn0Ra nUF4Qzjrfim9PQaCu5ruTRcuG3bi1vOudNMp7Wk4TpZ8csnuQhspwieUV/czfD/dUdjv HjP25Th3NohdFpa/N+1C4x2UDKX7jmu8N0vWOWOXjUTcuHjAPvzu/3qM5g1DoPGaBJgB g8p0ZeVs197SN4jqgvs86w7aEEBEhzlH7IGb/DMzmwlcGwWe7d1fw25citHrFrHftL+d vmOg== X-Gm-Message-State: AFqh2kp6dm6KJ6OOPUf+CcWyxkkAeYwMG959XYfn2bbKvD3Q+L5KX+tJ AV2Bl6mvYVT5vz22FwfGiqXqltegb2yDAE5b2duRPA== X-Google-Smtp-Source: AMrXdXuSR36GmVbjDPgUTeX4saKd1sSyRhGvbBjAG2pdjSju/GXYaL2gQ0TWNCxnQ2scE0lImMX/jg== X-Received: by 2002:a17:906:524b:b0:7c1:5098:907f with SMTP id y11-20020a170906524b00b007c15098907fmr62080864ejm.61.1673453697040; Wed, 11 Jan 2023 08:14:57 -0800 (PST) Received: from localhost ([217.111.27.204]) by smtp.gmail.com with ESMTPSA id v19-20020a509553000000b0046cbcc86bdesm6336970eda.7.2023.01.11.08.14.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jan 2023 08:14:56 -0800 (PST) Date: Wed, 11 Jan 2023 17:14:55 +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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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. >+----------+ >|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? >| +---+ | | | | | | | | +--------+ | >| 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 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 BE492C5479D for ; Wed, 11 Jan 2023 16:16:11 +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=0YhPmYbM5x/+TWjnzCCv/aQ9X1EIWv9TL/FfolVJ480=; b=usft7Tfr9WXGej kuFJ1Xaq6m/x/esrBcsiMqni3QSEnS32cZpsi4kR7PbEXjiwGxne7doLoVQhphMfvfwmfdz8VlUOa hVLX6FeoF6gpA87rLaLsoKR6rjpFZ07PkUmEGRKQ6Blzl+JKm8z+dWq93+SCdQLwNLIGJLPPsiBoc z56KnWIqufKF/UVRPEBTFuUb1Lr5TYJvSYBb6lwcdpqxNc97ArjpaYyIV3vRYFUTlJIngTbwH0Rzi qdmH7pIeT74VN4du95dmYOrR7RY9RZc08ess+5svt0qk80R92rOQsOtH5lqf8DjbGs/YC2wBBsCsN ym2VkffFfuxU84+pUMgg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFdkn-00C7kl-04; Wed, 11 Jan 2023 16:15:05 +0000 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFdki-00C7jV-EY for linux-arm-kernel@lists.infradead.org; Wed, 11 Jan 2023 16:15:03 +0000 Received: by mail-ej1-x62f.google.com with SMTP id qk9so38112008ejc.3 for ; Wed, 11 Jan 2023 08:14:59 -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=ZVgO94N/nb0C0chpJhGPxGhX0WKBJe9OSAqLZGN9MPA=; b=TVjIDl188h/cYo2yMId+ghWA1ae7nHMzsfPHhLnY2daGFnW+b3e89R33GuP68rIeAp j3TrKsoUXI4EuEGn3fI+WMO8VFRKMv7OrandqlXq0GxysjHRZ4YcKEcBHbNaiYwtVxFj HVYSg1LD09vSiAgZs/q9kyX1KvJu26kqlxNalwrN6H67diFhZ4MK8SYrmv9ayntnVYNM sk1UEabg3VPMK5+V8GQ0vHbaPhCFQR3hoJJi2xn/936eL3oCvvidmJUp3FA0tJjTMdfJ Pyke+8+TjLrhQU74BqiFcwLqS4N62KEbquTszcNAFDZsv25/gTrBFJRmV8TyE20mHq19 e/ow== 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=ZVgO94N/nb0C0chpJhGPxGhX0WKBJe9OSAqLZGN9MPA=; b=jLfuzZc/EWi5N2KV8cB0EJ39vbHZZlbga6/gBkWi9goRGR8Pq6NnnSMkN59K6LEy7n B0viAhj8S/6vNj92lrXgaH/kokjC3ErNWzKGdvLofHiJOiPOuDjIGIPh/kwVpLwx/C0D i33Ndvj2SgWNMLsgbw5yxOk49UJhF0MNJnqhURwya/bM4DZqFVo2nStNLq/03hC9BoqS 3sbUpt/+VbupM0YUe4DOmpmXwxTwpr02wbs7zmKpCpwhRyC8icE+rzXLOcE9JiRmyagy UfyHwtP6njgOybFVqS4AKVasRl8Dfebr1385drDbAvCm3YRcLCRMw3CQ7049ktIssMJR zRUw== X-Gm-Message-State: AFqh2koWAlz7w0I6CHCM40LBYTJsJLY7SvHxoPL8ndc2yb4D6KWFiQ+N i90aQR4zD09qV9KAiVFKrEjEng== X-Google-Smtp-Source: AMrXdXuSR36GmVbjDPgUTeX4saKd1sSyRhGvbBjAG2pdjSju/GXYaL2gQ0TWNCxnQ2scE0lImMX/jg== X-Received: by 2002:a17:906:524b:b0:7c1:5098:907f with SMTP id y11-20020a170906524b00b007c15098907fmr62080864ejm.61.1673453697040; Wed, 11 Jan 2023 08:14:57 -0800 (PST) Received: from localhost ([217.111.27.204]) by smtp.gmail.com with ESMTPSA id v19-20020a509553000000b0046cbcc86bdesm6336970eda.7.2023.01.11.08.14.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jan 2023 08:14:56 -0800 (PST) Date: Wed, 11 Jan 2023 17:14:55 +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-20230111_081500_730507_E4FAE023 X-CRM114-Status: GOOD ( 19.43 ) 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 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. >+----------+ >|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? >| +---+ | | | | | | | | +--------+ | >| 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