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 B51A1C4332F for ; Thu, 13 Oct 2022 15:18:33 +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=4bf2PpojGh7xFUyljv0gs4wEjdtDMbf3h9F2iM+wJjU=; b=unreAcdT7ZVHl8 5Dm9DRoBZKk1AcbQDtNPC0M+aIKrP7E0GYpukxxN/T6UjfinTHVXCnnjECm2chBDUvwVEJv07+Vxg btTPi/tmYoeRr2h9f2mIrQItp10rceMEInNK+o0AtvnZgrhn1IJZRC+PCTbzp7nBnIMKKwo0IbHF4 R+JyV32igxz9SV9iMutQ6UjfsNqo3HVrRFTnzOCh296rt60OXzJch2xIgHW56c0IuIJTb5a3zi7Dy B+GGuBR2VdS0B62cyJ+1AAHr+3Mli/5yzCPAkF2XG+VmBt71IFlyOE8gX8MPmUYuUIdtl0xreaD4L JHWCcCqSNzrgu0BjQq2Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oizxj-00CElv-DK; Thu, 13 Oct 2022 15:17:31 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oizxg-00CElT-0p for linux-arm-kernel@lists.infradead.org; Thu, 13 Oct 2022 15:17:29 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 7640C61802; Thu, 13 Oct 2022 15:17:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E8B7C433C1; Thu, 13 Oct 2022 15:17:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665674246; bh=yatlLHSqxUtoD/+/RComVTMF7cyfCFtUK70jh+/Y9Uo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RB8lMH2hYP38YlLrXrCjPDqpjWmw50pNmZ/FDXhc0H1/QrFnAd7uUwk6xYhvF7Kq0 ncH7WKj7vDvdXHbMDiwA/KRvN8M2J8jESXLB85tVkBXKoYwi/v1W0eqTMbEr7IK+jA VWiCsg2DCDyC5muKC2bmNJc5adbmKARJv+0E7KLfTSt2V3j5HGd7Ldxtm+K0vy/lOl mPyxpyHuUNkH/nDRsh30fIhllowV505ra9GYb0h9MKjBkF3nAIYDbUbuB+kqbyRUxc FFju9UcX3ke8DiOVxri/grlyjMKpV1MCXZRT4n+plYDrlBX6FswdKRMKsHTFSEFk3d SToMZnvLpr0Cw== Date: Thu, 13 Oct 2022 08:17:25 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: Vadim Fedorenko , Arkadiusz Kubalewski , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, Vadim Fedorenko Subject: Re: [RFC PATCH v3 1/6] dpll: Add DPLL framework base functions Message-ID: <20221013081725.501b0f58@kernel.org> In-Reply-To: References: <20221010011804.23716-1-vfedorenko@novek.ru> <20221010011804.23716-2-vfedorenko@novek.ru> <24d1d750-7fd0-44e2-318c-62f6a4a23ea5@novek.ru> <9a3608cf-21bb-18b1-796a-7325a613b641@novek.ru> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221013_081728_127034_9A0A8218 X-CRM114-Status: GOOD ( 16.86 ) 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 Thu, 13 Oct 2022 08:55:34 +0200 Jiri Pirko wrote: >> AFAIU, some mux devices are not smart enough to make a decision suitable for >> autoselect for the pins they have. In this case the autoselect process is >> done in the DPLL device, which selects mux and not the pin directly. At the >> same time there could be muxes that are smart enough to make a decision, and >> it will be autoselect on top of autoselect (and several more layers) and it >> doesn't sound great to me. I believe Arkadiusz will explain the mux a bit >> better. > > From what you write in this reply, I have a feeling that these details > are not really interesting for user to see. So I tend to lean forward to > abstract this out and leave the details to HW/FW/driver. Are you saying we don't need to model MUXes? Topology of the signals imposes restrictions on the supported configuration, it's not something you can "abstract out in the FW". My thinking was we can let the user ignore it and have the core figure out the configuration of the muxes if users asks for a pin behind a mux. But it's better if the mux is visible so that it's clear which signals can't be selected simultaneously. (IIRC Arkadiusz may have even had muxes shared between DPLLs :S) Anyway, I may just be confused about the state of the series because most of the points you brought up were already discussed. I guess you were right that off-list reviews are a bad idea :( _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel