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 F14F5C352A1 for ; Wed, 7 Dec 2022 14:10:30 +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:Message-ID:Date:Subject: In-Reply-To:References:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qOdatV3b2lat4NSciVlNPiLE5nZr02FMOxE9KiVutsI=; b=s8ujNrTUPwWucP NSfgx0Pc49/4M7SPadX9vuSu+O2/stQAc0PCVDzUdl/SGtD0/3D1YHvwhFR6s4T5xs0pZCeLkypsk 6H7kJvQOoXw6I67Y36+rLnK7CqMOiCT1MS5wwF58tzfLBGk/2hFfAU43RDYPdenZTAxFiikRcTzAK PI+PwLHyRwTkxdAm0T1aDrnGsmSnr+uNJLr5wEI077+PpKvTmiJr51K4lQS5hy3CLGNPa2hZwveLt 9Lq6GMr+MVwTPjGWrqLIPjEretOg+t/qfrazPjHCrdp69kNubDTmXyweOPMX6RMsibt0WjXeDaH0I hYjYAZeVZUNmQZvpqTMw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p2v6o-004XGU-Iw; Wed, 07 Dec 2022 14:09:15 +0000 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p2v6j-004X5O-3T for linux-arm-kernel@lists.infradead.org; Wed, 07 Dec 2022 14:09:10 +0000 Received: by mail-ej1-x629.google.com with SMTP id bj12so14198668ejb.13 for ; Wed, 07 Dec 2022 06:09:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=HfRbWXj1ryZ5GigKdlnSpxHeKcoIXzKhe5JQwEmq1f8=; b=WHXdNthSpVMYh8TQeOUuH5dQ6K2I04nxBLe8eERBlRWZkH4jajaNfBC0xcirw+9zXc CzRsbbjgCTnKewSdaeR4Q8eIh66aNHe6uOcVN1E+QQlKshfcLwooa98jI01bExdaEJCh QBsci2ey5uTCe2L4RFyUY1Nxzk7MYoGJnP0Q+HKqs5Y8vMbX+zU+YiX6ySKpK4odMiD7 BS3aUnVW4pjXvvI7H7uHZ552LImRc5bci8nhyJz4QrMQJYjO71AptlKHBpWzwoNtmwDx 4mFe41gdZgdKn+sksY0zTJsXMoVL10ffFKOTTauBEcCQEDI55eHiMwbVRDJV+92d7REk 77ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HfRbWXj1ryZ5GigKdlnSpxHeKcoIXzKhe5JQwEmq1f8=; b=C5UCebb1Wk+3yHJ68KzD/HAiGcVyuFmqCCBLYaF07WH/EnNn8ZoNc8Q9cNfmZP4CLI kqibS9yFJEUjHtjlC0A2tTvSHc/wWToUwCKfJnTrqXM3fKGFIE4Z2LjHkpgEm63Cbx6/ h3L900pN7gXXT2l9s1ClbwYUp93JDZiFtCfHuWQQO0Z4CzPE0W4Xn0a4m9WdfipAbnEH shDJ+Kulbp8UCR4gcoot+QU7VXUgM+0OtTKH7viNfOnCumsOO/dJ39WcnsrB98YFSJzk wU6JTwGRtY77uHxUJ8EY8BoGVWicKnHe/P+6R/YIk+qpz5DQADfQX7eQQowBGdWxkNVn McKg== X-Gm-Message-State: ANoB5pnXlL5BJ8fvN/SjGq+aiTw0yWMfeLwWrMOFJjCill0Co1mFsrBz v3Ko/ayB0y0PPr0TS06F9B4= X-Google-Smtp-Source: AA0mqf7ZnHqgf3A3Z9YTz+W3oqPd9lBAUCzC6xkNs7SctMaeg0v9SYT3FuDRMeLl+p9+puQm5h6pJw== X-Received: by 2002:a17:906:22d6:b0:7c0:9e25:8908 with SMTP id q22-20020a17090622d600b007c09e258908mr27501905eja.673.1670422145680; Wed, 07 Dec 2022 06:09:05 -0800 (PST) Received: from NVBTQK6D3 (83.8.188.9.ipv4.supernova.orange.pl. [83.8.188.9]) by smtp.gmail.com with ESMTPSA id du1-20020a17090772c100b00772061034dbsm8580812ejc.182.2022.12.07.06.09.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2022 06:09:05 -0800 (PST) From: To: "'Jakub Kicinski'" , "'Jiri Pirko'" Cc: "'Kubalewski, Arkadiusz'" , "'Vadim Fedorenko'" , "'Jonathan Lemon'" , "'Paolo Abeni'" , , , References: <20221129213724.10119-1-vfedorenko@novek.ru> <20221206184740.28cb7627@kernel.org> In-Reply-To: <20221206184740.28cb7627@kernel.org> Subject: RE: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Date: Wed, 7 Dec 2022 15:09:03 +0100 Message-ID: <10bb01d90a45$77189060$6549b120$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGuvSISvoht30pwfXCmDPUNHV3PZAJbzGJCAQIu/1AB4Mb46wHXujcVrn5LKlA= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221207_060909_177910_AC6CAF17 X-CRM114-Status: GOOD ( 36.55 ) 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 > -----Original Message----- > From: Jakub Kicinski > Sent: Wednesday, December 7, 2022 3:48 AM > Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API > > On Fri, 2 Dec 2022 17:12:06 +0100 Jiri Pirko wrote: > > >But this is only doable with assumption, that the board is internally capable > > >of such internal board level communication, which in case of separated > > >firmwares handling multiple dplls might not be the case, or it would require > > >to have some other sw component feel that gap. > > > > Yep, you have the knowledge of sharing inside the driver, so you should > > do it there. For multiple instances, use in-driver notifier for example. > > No, complexity in the drivers is not a good idea. The core should cover > the complexity and let the drivers be simple. But how does Driver A know where to connect its pin to? It makes sense to share pins between the DPLLs exposed by a single driver, but not really outside of it. And that can be done simply by putting the pin ptr from the DPLLA into the pin list of DPLLB. If we want the kitchen-and-sink solution, we need to think about corner cases. Which pin should the API give to the userspace app - original, or muxed/parent? How would a teardown look like - if Driver A registered DPLLA with Pin1 and Driver B added the muxed pin then how should Driver A properly release its pins? Should it just send a message to driver B and trust that it will receive it in time before we tear everything apart? There are many problems with that approach, and the submitted patch is not explaining any of them. E.g. it contains the dpll_muxed_pin_register but no free counterpart + no flows. If we want to get shared pins, we need a good example of how this mechanism can be used. > > > >For complex boards with multiple dplls/sync channels, multiple ports, > > >multiple firmware instances, it seems to be complicated to share a pin if > > >each driver would have own copy and should notify all the other about > changes. > > > > > >To summarize, that is certainly true, shared pins idea complicates stuff > > >inside of dpll subsystem. > > >But at the same time it removes complexity from all the drivers which would > use > > > > There are currently 3 drivers for dpll I know of. This in ptp_ocp and > > mlx5 there is no concept of sharing pins. You you are talking about a > > single driver. > > > > What I'm trying to say is, looking at the code, the pin sharing, > > references and locking makes things uncomfortably complex. You are so > > far the only driver to need this, do it internally. If in the future > > other driver appears, this code would be eventually pushed into dpll > > core. No impact on UAPI from what I see. Please keep things as simple as > > possible. > > But the pin is shared for one driver. Who cares if it's not shared in > another. The user space must be able to reason about the constraints. > > You are suggesting drivers to magically flip state in core objects > because of some hidden dependencies?! > If we want to go outside the device, we'd need some universal language to describe external connections - such as the devicetree. I don't see how we can reliably implement inter-driver dependency otherwise. I think this would be better served in the userspace with a board-specific config file. Especially since the pins can be externally connected anyway. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel