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 039C2C433FE for ; Fri, 14 Oct 2022 09:54:17 +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=6hsmyFETlKlB3u9pxhFGTkvJwsO6Kri0EGj8lkFuyhI=; b=g3nhnlvKlX5fwe h+82FPIKMjEmBxwMbXyiBcoqsiNe70k9/L++bBHUAubdcml9N5hQzB9sEsA/yqUgPa/OttzhQu6rs SIsFKAw5ubDAFF3ekFyPH+nULOpf20KPHLJW9vwenOxhZmBl15h7PlByBXny53hFEw5AsaHXzg9hp CmOCDuYY6cXgxMbStXYT78RoxrLyeuWw/k8sGkUmwe7MybIGyvQvMu7F+qsBJg+3iH9CgpLyvuvOn c8mIEDUAr81YGoLS5vj5Zcd6bWRxx9vrJSkDJS5V0FC8iNfu712b2TaNXl4zH9btSJYdbFQJ1+kj5 AYdnSJI01U0U7nMq+Bmw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ojHNC-00EKEU-Ow; Fri, 14 Oct 2022 09:52:59 +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 1ojHMg-00EK10-Px for linux-arm-kernel@lists.infradead.org; Fri, 14 Oct 2022 09:52:29 +0000 Received: by mail-ej1-x636.google.com with SMTP id a26so9362774ejc.4 for ; Fri, 14 Oct 2022 02:52:23 -0700 (PDT) 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=299L7Zs/XJUb9u6JhyOpi3WgUrHdMmQAEsWR3uOjIYc=; b=JOTiuopG8km3XtuX5HfQFp6ORVzx7LLvrQ2isr87H2o5ZimMUKe+djV7os1u6GUxAP tSKR4RAfbO9EhFwI3uwa+u18qUlWC9nH2ssNu3hbQLb8mIJOLk3wL7WiyhA8kJSGWEyx hpvtalFBKFgSm6cbXN8Rl9q32sGNmoUv340a1u3xTJ6AqmYOvWFT7Ruacnf3Lr6Fav+0 sT2/vAhaRTM1qmqtW6R7GsgGlA8MEIa2exqjVXqfq6uQviD/eXlsqgZ0SrCjNaNuHg7G Kd2hP4B5H6zkXVv2FzsaC7r8W5QRauYiVEtw8yC5jEkN0HogjFHHdsGibILaGmY6UZT6 pm1w== 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=299L7Zs/XJUb9u6JhyOpi3WgUrHdMmQAEsWR3uOjIYc=; b=LzbH+Ndl51M0sHPc4CrP5+RiY9qbZAgv0q89F4jgqfn/HK6gd21QCDj/tChrisCJfZ nAnlJG7tNDLg9ITsqqTN7DFin0GnqUgjNCik+N6RLI6DfWRO7yQCHzWBF2thjrIv42/2 sXSFsEUNjpvjrQfGT/ZpEbvI5rjXWWISOOjNdBf6fx/svO1TWiRCdGY3/AbXifKhVIxD 8NA61T/JZ2HJ+5siFfbGnG5ns5tISFDB7+QzhL7BDJM/8RH2l34e+PPzJ6wUMDFzyyyZ t+y+IhK3F2l5b4C8F4lB9eQXmYW+T4JS+NdW+R1cOgATQvni87dSyP9+gTsCjMMVFK23 6QaQ== X-Gm-Message-State: ACrzQf0EVSsRkEbCwx0zWxiT/18PtWfrnjXk+RJIjJz/PI+iLQLEtC4k zZeUgpLomakdR1pCV21rd0lC9g== X-Google-Smtp-Source: AMsMyM6e+X4YGgA/fu0UmpKGVoZyo9IBlfy1KHM0430kLf7hh912Jq/15taqlNOl5o46hecGERfePw== X-Received: by 2002:a17:906:4fcd:b0:78d:8059:17c with SMTP id i13-20020a1709064fcd00b0078d8059017cmr3005758ejw.423.1665741142164; Fri, 14 Oct 2022 02:52:22 -0700 (PDT) Received: from localhost ([86.61.181.4]) by smtp.gmail.com with ESMTPSA id z10-20020a170906714a00b0078b4801c40bsm1208101ejj.216.2022.10.14.02.52.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Oct 2022 02:52:21 -0700 (PDT) Date: Fri, 14 Oct 2022 11:52:20 +0200 From: Jiri Pirko To: Jakub Kicinski 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: References: <20221010011804.23716-2-vfedorenko@novek.ru> <24d1d750-7fd0-44e2-318c-62f6a4a23ea5@novek.ru> <9a3608cf-21bb-18b1-796a-7325a613b641@novek.ru> <20221013081725.501b0f58@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221013081725.501b0f58@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221014_025227_131747_B8F9CA11 X-CRM114-Status: GOOD ( 18.42 ) 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, Oct 13, 2022 at 05:17:25PM CEST, kuba@kernel.org wrote: >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) Yeah, that sounds fine. My point was, the user does not have to know the details and muxes could be abstracted out in kernel and below. Not sure why the mux would need to be visible to user. It it needs to, sure, lets model it. I have no strong opinion here. > >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 :( Yep :/ Let's please move it here to stop the mess. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel