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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB3A2C433F5 for ; Tue, 26 Oct 2021 11:01:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF4D960C4A for ; Tue, 26 Oct 2021 11:01:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235393AbhJZLD3 (ORCPT ); Tue, 26 Oct 2021 07:03:29 -0400 Received: from smtp-relay-internal-0.canonical.com ([185.125.188.122]:43762 "EHLO smtp-relay-internal-0.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235357AbhJZLDV (ORCPT ); Tue, 26 Oct 2021 07:03:21 -0400 Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id E0AF33F173 for ; Tue, 26 Oct 2021 11:00:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1635246053; bh=saCQu9EKQs4I6SKXkv5FjAbPTAvRNyG3cbYVa3bkKDU=; h=To:Cc:References:From:Subject:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=Z6cJ2pbbSnIn9uVxehdiOgI61pnh3GkFannE2EWHWf5bvqVeJLcFi8seGsGXtvYne O6D7tI3wFUlcpSpqsZuwSkaF2vZFQ3Ajb68lmDNYIlLBv/8YWNCB7LWwNQnTG0sqK5 /UDOOZSBtq+x2ZPb42R49kcMtiH2mc9JdDgUdcXHJgvbwcmXgUZQdDMeoPVutH67EK Vbc11/35yFp66kftX76j/qV+pCL1geZyhcJYkLxTdMMaMRxl/hpL5KkcsA3HgL+TH1 hNmpYSzgI0+Gt1fb+SBOIA0+TywovvBNuRuHsYphkC+6Ij0unZqr6oZmFac2aiXHeW gZOMcjmb/Ga6g== Received: by mail-lj1-f199.google.com with SMTP id d24-20020a2eb058000000b00211892e18f2so1236776ljl.8 for ; Tue, 26 Oct 2021 04:00:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=saCQu9EKQs4I6SKXkv5FjAbPTAvRNyG3cbYVa3bkKDU=; b=u4Wv0JuKurj3/Y+/IysUCkNZwyfHHk7Da47sQ7suluTlMjYjYT0k0g+q7fln38huav m+SD5jlqwZ3L0bYaoVmqdu7PLljB5xWeyPqNw16pXXBCU5ib63cQKzkripcgr0zHpnCs w/77hxsHmLtFAbKx0/y9QfF5/9494alvT+HoiBKkJE4b8YPmgst98incKcd1g8v7UvL1 ysJ79tuoynSGUeNADBXRdfHL0Nz3lP1gnUvWYY6cvsjdTzO+EkYy1XnZuWxUmSz8A8oy CsMcs6nT5p+RUtGoe3oN5ReSpcDZLXfXHBlBWwHOANpkUUcsLC2pcJPqDP8C554E5QW3 /ALw== X-Gm-Message-State: AOAM533+wq+Q3Txms/9clwN50xm+kU63EgwDHga1M314gfhfh+fCj9qU OnXlpRXIlhOVrgh9t6OPqPOtomT9ZBmB65k25Limmzf+KMFLOh/J659EE37QHIJ3buJ2fw7j6lh ImRMG75D6uWB6CWIgXBk2GamJp8g5NTYwkrNTp9kbhA== X-Received: by 2002:a2e:8605:: with SMTP id a5mr6639004lji.107.1635246053199; Tue, 26 Oct 2021 04:00:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxu6cel0oQC1BuMesrfNH59P19SIT7Z0msL6k//HhV+BZ9TfGDzQ+R+3+GvGDhor/q3GvReFQ== X-Received: by 2002:a2e:8605:: with SMTP id a5mr6638964lji.107.1635246052925; Tue, 26 Oct 2021 04:00:52 -0700 (PDT) Received: from [192.168.3.161] (89-77-68-124.dynamic.chello.pl. [89.77.68.124]) by smtp.gmail.com with ESMTPSA id n7sm1985531ljg.47.2021.10.26.04.00.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Oct 2021 04:00:52 -0700 (PDT) To: Youngmin Nam , Will Deacon , Mark Rutland , daniel.lezcano@linaro.org Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, pullip.cho@samsung.com, hoony.yu@samsung.com, hajun.sung@samsung.com, myung-su.cha@samsung.com, kgene@kernel.org References: <20211021061804.39118-1-youngmin.nam@samsung.com> <20211021061804.39118-2-youngmin.nam@samsung.com> <0c5dcdab-7aa3-a98f-e615-acbe98489935@canonical.com> <20211021082650.GA30741@perf> <1b93aaf3-ed64-b105-dec4-07b6f27b385b@canonical.com> <20211022042116.GA30645@perf> <20211026014732.GA45525@perf> <91e926c4-9a3a-196d-1451-d3e7d38fc132@canonical.com> <20211026104518.GA40630@perf> From: Krzysztof Kozlowski Subject: Re: [PATCH v1 1/2] clocksource/drivers/exynos_mct_v2: introduce Exynos MCT version 2 driver for next Exynos SoC Message-ID: Date: Tue, 26 Oct 2021 13:00:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20211026104518.GA40630@perf> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/10/2021 12:45, Youngmin Nam wrote: > On Tue, Oct 26, 2021 at 09:10:28AM +0200, Krzysztof Kozlowski wrote: >> On 26/10/2021 03:47, Youngmin Nam wrote: >>>> If everyone added a new driver to avoid integrating with existing code, >>>> we would have huge kernel with thousands of duplicated solutions. The >>>> kernel also would be unmaintained. >>>> >>>> Such arguments were brought before several times - "I don't want to >>>> integrating with existing code", "My use case is different", "I would >>>> need to test the other cases", "It's complicated for me". >>>> >>>> Instead of pushing a new vendor driver you should integrate it with >>>> existing code. >>>> >>> Let me ask you one question. >>> If we maintain as one driver, how can people who don't have the new MCT test the new driver? >> >> I assume you talk about a case when someone else later changes something >> in the driver. Such person doesn't necessarily have to test it. The same >> as in all other cases (Exynos MCT is not special here): just ask for >> testing on platform one doesn't have. >> >> Even if you submit this as separate driver, there is the exact same >> problem. People will change the MCTv2 driver without access to hardware. >> > Yes, I can test the new MCT driver if someone ask for testing after modifying the new driver. > But in this case, we don't need to test the previous MCT driver. We have only to test the new MCT driver. Like with everything in Linux kernel. We merge instead of duplicate. It's not an argument. >> None of these differ for Exynos MCT from other drivers, e.g. mentioned >> Samsung PMIC drivers, recently modified (by Will and Sam) the SoC clock >> drivers or the ChipID drivers (changed by Chanho). > From HW point of view, the previous MCT is almost 10-year-old IP without any major change and > it will not be used on next new Exynos SoC. > MCTv2 is the totally newly designed IP and it will replace the Exynos system timer. > Device driver would be dependent with H/W. We are going to apply a lot of changes for this new MCT. > For maintenance, I think we should separate the new MCT driver for maintenance. > There are several similarities which actually suggest that you exaggerate the differences. The number of interrupts is the same (4+8 in older one, 12 in new one...). You assign the MCT priority also as higher than Architected Timer (+Cc Will and Mark - is it ok for you?) evt->rating = 500; /* use value higher than ARM arch timer * All these point that block is not different. Again, let me repeat, we support old Samsung PMICs with new Samsung PMICs in one driver. Even though the "old one" won't be changed, as you mentioned here. The same Samsung SoC clock drivers are used for old Exynos and for new ones... Similarly to pinctrl drivers. The same ChipId. Everywhere we follow the same concept of unification instead of duplication. Maybe Exynos MCT timer is an exception but you did not provide any arguments supporting this. Why Exynos MCTv2 should be treated differently than Exynos850 clocks, chipid, pinctrl and other blocks? Daniel, Any preferences from you? Integrating MCT into existing driver (thus growing it) or having a new one? Best regards, Krzysztof 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43B6AC433EF for ; Tue, 26 Oct 2021 11:02:32 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 0D76160C4A for ; Tue, 26 Oct 2021 11:02:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0D76160C4A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Date: Message-ID:Subject:From:References:Cc:To:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=O+3uc/fLZKXaBtWcCERcdVMU/bJBJv0eiKkY2LENni8=; b=VBS6jswK288uBKK3T4hk0VwV0h y/Ma7V9qXaXsinHETYlXCtevn79tdrJfMSeTTl7UH7th1kTsBYwBKtqsJwuxycRYVWjaVzOBME0+6 0f+5Hre0boH1FqbObweNMs5ReRbAVGl2Ko3bTdptUrVFJpd0ROmtdNO5JNy3XDqfpHC3oa6LaWHVN MH8lGIvJ7xCbDV6NkSyZhkAVxySVZ15hK2A2SDMS2JfQDP++NaBu7kkWxCGQyt5I6x8apLeQBL6yR tfxM2Eumv8WPYExTSNm5AIu8HpEKHTX19BYA+q24JJZAfZH/jhK9U90Cth/RNyE6+vEhgYKboOqN9 hYA5aTNw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfKCY-001a4k-LX; Tue, 26 Oct 2021 11:01:07 +0000 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfKCR-001a2m-BT for linux-arm-kernel@lists.infradead.org; Tue, 26 Oct 2021 11:01:01 +0000 Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id CB4C040279 for ; Tue, 26 Oct 2021 11:00:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1635246053; bh=saCQu9EKQs4I6SKXkv5FjAbPTAvRNyG3cbYVa3bkKDU=; h=To:Cc:References:From:Subject:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=Z6cJ2pbbSnIn9uVxehdiOgI61pnh3GkFannE2EWHWf5bvqVeJLcFi8seGsGXtvYne O6D7tI3wFUlcpSpqsZuwSkaF2vZFQ3Ajb68lmDNYIlLBv/8YWNCB7LWwNQnTG0sqK5 /UDOOZSBtq+x2ZPb42R49kcMtiH2mc9JdDgUdcXHJgvbwcmXgUZQdDMeoPVutH67EK Vbc11/35yFp66kftX76j/qV+pCL1geZyhcJYkLxTdMMaMRxl/hpL5KkcsA3HgL+TH1 hNmpYSzgI0+Gt1fb+SBOIA0+TywovvBNuRuHsYphkC+6Ij0unZqr6oZmFac2aiXHeW gZOMcjmb/Ga6g== Received: by mail-lj1-f198.google.com with SMTP id f6-20020a2e9e86000000b00211349f9ce3so4170641ljk.3 for ; Tue, 26 Oct 2021 04:00:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=saCQu9EKQs4I6SKXkv5FjAbPTAvRNyG3cbYVa3bkKDU=; b=i6ub4mOtUGyRbLBBL7y2p3bQslWff47SW5nrwI290n3I3XSt+mqZDFMR50Y2NmBsSM 6vqXnRMPC9AqyP83AkbhGu1VbGJuLtN5hYOvND8Gy41DI/XKB0nB2dYsHBp06VWHZZHT eTupJpHktXAhXbcDA5SJMk4zvbVeXFo7IsldtyY8aSb0UZFQYyteh5tDS1U4r05ZiLCC MlAiVxWzLKyA5BBhJZO0nGlpQa22pQosc8MRVuHHGeVUMP+kAWGAJUyRRncxb737guDu meQ45JqZl3y9VDRVTSnPwVJvjzhGvqdPelsZd7pqCc/B/iDGvmtPP3mKX9xAb3jPubux NTMQ== X-Gm-Message-State: AOAM532F/U2vJST3kRsUVgr/gGS0Vm02hNtdkxuEouqV0SHWqwNMjOOz cCyWLDnO2DM1n0FCzNft6kvHvx3zXK+L3xLbl2wG0QMxIdek6eYMTP56QSh1ra+GJQLxCeFxV4H mhExCF1v91T2nK1eCa7MzlKQSMBwdBYw7Di7Ysg6G+e5afvHd0XlO X-Received: by 2002:a2e:8605:: with SMTP id a5mr6638985lji.107.1635246053122; Tue, 26 Oct 2021 04:00:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxu6cel0oQC1BuMesrfNH59P19SIT7Z0msL6k//HhV+BZ9TfGDzQ+R+3+GvGDhor/q3GvReFQ== X-Received: by 2002:a2e:8605:: with SMTP id a5mr6638964lji.107.1635246052925; Tue, 26 Oct 2021 04:00:52 -0700 (PDT) Received: from [192.168.3.161] (89-77-68-124.dynamic.chello.pl. [89.77.68.124]) by smtp.gmail.com with ESMTPSA id n7sm1985531ljg.47.2021.10.26.04.00.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Oct 2021 04:00:52 -0700 (PDT) To: Youngmin Nam , Will Deacon , Mark Rutland , daniel.lezcano@linaro.org Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, pullip.cho@samsung.com, hoony.yu@samsung.com, hajun.sung@samsung.com, myung-su.cha@samsung.com, kgene@kernel.org References: <20211021061804.39118-1-youngmin.nam@samsung.com> <20211021061804.39118-2-youngmin.nam@samsung.com> <0c5dcdab-7aa3-a98f-e615-acbe98489935@canonical.com> <20211021082650.GA30741@perf> <1b93aaf3-ed64-b105-dec4-07b6f27b385b@canonical.com> <20211022042116.GA30645@perf> <20211026014732.GA45525@perf> <91e926c4-9a3a-196d-1451-d3e7d38fc132@canonical.com> <20211026104518.GA40630@perf> From: Krzysztof Kozlowski Subject: Re: [PATCH v1 1/2] clocksource/drivers/exynos_mct_v2: introduce Exynos MCT version 2 driver for next Exynos SoC Message-ID: Date: Tue, 26 Oct 2021 13:00:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20211026104518.GA40630@perf> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211026_040059_632536_79401DD9 X-CRM114-Status: GOOD ( 32.34 ) 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 26/10/2021 12:45, Youngmin Nam wrote: > On Tue, Oct 26, 2021 at 09:10:28AM +0200, Krzysztof Kozlowski wrote: >> On 26/10/2021 03:47, Youngmin Nam wrote: >>>> If everyone added a new driver to avoid integrating with existing code, >>>> we would have huge kernel with thousands of duplicated solutions. The >>>> kernel also would be unmaintained. >>>> >>>> Such arguments were brought before several times - "I don't want to >>>> integrating with existing code", "My use case is different", "I would >>>> need to test the other cases", "It's complicated for me". >>>> >>>> Instead of pushing a new vendor driver you should integrate it with >>>> existing code. >>>> >>> Let me ask you one question. >>> If we maintain as one driver, how can people who don't have the new MCT test the new driver? >> >> I assume you talk about a case when someone else later changes something >> in the driver. Such person doesn't necessarily have to test it. The same >> as in all other cases (Exynos MCT is not special here): just ask for >> testing on platform one doesn't have. >> >> Even if you submit this as separate driver, there is the exact same >> problem. People will change the MCTv2 driver without access to hardware. >> > Yes, I can test the new MCT driver if someone ask for testing after modifying the new driver. > But in this case, we don't need to test the previous MCT driver. We have only to test the new MCT driver. Like with everything in Linux kernel. We merge instead of duplicate. It's not an argument. >> None of these differ for Exynos MCT from other drivers, e.g. mentioned >> Samsung PMIC drivers, recently modified (by Will and Sam) the SoC clock >> drivers or the ChipID drivers (changed by Chanho). > From HW point of view, the previous MCT is almost 10-year-old IP without any major change and > it will not be used on next new Exynos SoC. > MCTv2 is the totally newly designed IP and it will replace the Exynos system timer. > Device driver would be dependent with H/W. We are going to apply a lot of changes for this new MCT. > For maintenance, I think we should separate the new MCT driver for maintenance. > There are several similarities which actually suggest that you exaggerate the differences. The number of interrupts is the same (4+8 in older one, 12 in new one...). You assign the MCT priority also as higher than Architected Timer (+Cc Will and Mark - is it ok for you?) evt->rating = 500; /* use value higher than ARM arch timer * All these point that block is not different. Again, let me repeat, we support old Samsung PMICs with new Samsung PMICs in one driver. Even though the "old one" won't be changed, as you mentioned here. The same Samsung SoC clock drivers are used for old Exynos and for new ones... Similarly to pinctrl drivers. The same ChipId. Everywhere we follow the same concept of unification instead of duplication. Maybe Exynos MCT timer is an exception but you did not provide any arguments supporting this. Why Exynos MCTv2 should be treated differently than Exynos850 clocks, chipid, pinctrl and other blocks? Daniel, Any preferences from you? Integrating MCT into existing driver (thus growing it) or having a new one? Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel