From patchwork Tue Jul 11 20:35:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Halaney X-Patchwork-Id: 13309383 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 CC55BEB64DC for ; Tue, 11 Jul 2023 20:58:40 +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:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=Rv7o5UCQqxvGtSeV+N5q9QN7Egsvm6Hje8w/qHw5uPs=; b=FyfPQ36JRefVbZ 9QpR+yTdoZIS+d8QnT980BoyC7MvrChnXr2coSqf4BQS401+/jreEYZpOXGMbxHpcORxUTlUO3yLe ZwyfmavoxxX/q1SKlczJyIzRS54Lnq+mvg7t58DNhB1oMIOGc6tm/3/PIYKATG8la1GE1Zk2UE4Ds jUBxq1HafBT4lmXUQoh59kAWpu4G+cEiauGWXsUeWs9tbnVMDjoT0DwFhHa5ce9XUFh+Ip1IMzxUB CzaNtiisrJ3Gw9ygljOGbmebVCAB4QntGhZ19Se74PoOYnTaAZjhfS9n2Fdm+1HPVobDqEJtSxsfk ja9DYCTNP4YfLUgXoqKw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qJKR2-00Fsen-0M; Tue, 11 Jul 2023 20:58:12 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qJKQy-00Fsdm-21 for linux-arm-kernel@lists.infradead.org; Tue, 11 Jul 2023 20:58:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689109084; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=f+hIo3oC9fPc83S0WFvpQBdDffxEHtx3wU0gPObo34Y=; b=Ddwi4WcbvYdl9J5pRzVzBAMxiEqynnbuzK26TEgjpER/U6zs/+Ct+8gTljUhRqa/AkMj/0 iqrnqvKJAp8PwQs9+tyJX7J9vKkEHQXt3GztgGXxr6MVLgklXfJZ0Ek6X6aofjeFi8JjM0 AJf/a/5tZLKUTSyfm06hnYQ1od4lijA= Received: from mail-yw1-f197.google.com (mail-yw1-f197.google.com [209.85.128.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-494-PVYCfKlQMyagzJApB-ZGIw-1; Tue, 11 Jul 2023 16:58:03 -0400 X-MC-Unique: PVYCfKlQMyagzJApB-ZGIw-1 Received: by mail-yw1-f197.google.com with SMTP id 00721157ae682-5618857518dso50202577b3.2 for ; Tue, 11 Jul 2023 13:58:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689109082; x=1691701082; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=f+hIo3oC9fPc83S0WFvpQBdDffxEHtx3wU0gPObo34Y=; b=Z5cxrP+jU8TtOZovTnE4zYzwefedZNTKeL46tJ8xsr2MEbhp0cATLnWeKHbY/G81Ph gmxElTk2Z/Bz0B/AOYOqNa8Siq8HoAY52dpxstzZzBZuAPWuK7HM+Q5VXvJXyNntleM5 z5LzEYOlUt27FVL9lEju4KNOurG2S1cgAy2m4W2E1xs0ISwnOw6C6Bo1DmMCpc7keY7x YAVXR2gssBv8fhiDEikyyA2bQJbdIamuD24emqwvGNT/FZPFAx4ud369+icasWbBQk1r rtqMDkChqwUcERM8yfEoDMA2U1SqN6s1dH/D1BSEOSpRr/7SVYzbYTl6lVF4Z2beniMv ILjg== X-Gm-Message-State: ABy/qLY8ygBu9Vodokboy1Zf9X0cPwXk6GgJc4FRMD5l1eQxU9aNGv5L L4GbCEBdW7wbZeDuAmfgRjz5/pTPxz4Gjf+KpmTJhwmqQVXvbAY7me8Be9L97sMXu646+A/q0QB We+4HMYpZcP1rgWLQ2a8yYbE9TLcE8SXbwSk= X-Received: by 2002:a0d:e284:0:b0:570:28a9:fe40 with SMTP id l126-20020a0de284000000b0057028a9fe40mr16227294ywe.5.1689109082640; Tue, 11 Jul 2023 13:58:02 -0700 (PDT) X-Google-Smtp-Source: APBJJlGA6n45gkHkTv6XI6HgkyWTiJIRi19JmwhiTyxapecnmiZP7znNfnQP5MUvwPurdzpN+R7zUA== X-Received: by 2002:a0d:e284:0:b0:570:28a9:fe40 with SMTP id l126-20020a0de284000000b0057028a9fe40mr16227284ywe.5.1689109082375; Tue, 11 Jul 2023 13:58:02 -0700 (PDT) Received: from halaney-x13s.attlocal.net ([2600:1700:1ff0:d0e0::22]) by smtp.gmail.com with ESMTPSA id j136-20020a81928e000000b00545a08184cesm785353ywg.94.2023.07.11.13.58.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jul 2023 13:58:02 -0700 (PDT) From: Andrew Halaney To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org, mcoquelin.stm32@gmail.com, pabeni@redhat.com, kuba@kernel.org, edumazet@google.com, davem@davemloft.net, joabreu@synopsys.com, alexandre.torgue@foss.st.com, peppe.cavallaro@st.com, bhupesh.sharma@linaro.org, vkoul@kernel.org, linux-arm-msm@vger.kernel.org, jsuraj@qti.qualcomm.com, Andrew Halaney Subject: [PATCH RFC/RFT net-next 0/3] net: stmmac: Increase clk_ptp_ref rate Date: Tue, 11 Jul 2023 15:35:29 -0500 Message-ID: <20230711205732.364954-1-ahalaney@redhat.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230711_135808_753920_F0F266E0 X-CRM114-Status: GOOD ( 18.98 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DO NOT MERGE, patch 2 and 3 are duplications at differing levels (platform vs driver wide). They work fine together but it makes no sense to take both. Disclosure: I don't know much about PTP beyond what you can google in an afternoon, don't have access to documentation about the stmmac IP, and have only tested that (based on code comments and git commit history) the programming of the subsecond register (and the clock rate) makes more sense with these changes. I'm hoping to start some discussion and get some insight about this. Recently I found myself discussing PTP and some possible changes from downstream that might need to be upstreamed. In doing so, I noticed that the PTP reference clock (clk_ptp_ref) was running at a much lower value than was being discussed. Digging in a bit, nobody is calling clk_set_rate() of any value on clk_ptp_ref, so you get whatever the default rate is when enabled. On Qualcomm platforms I have access to this results in a 19.2 MHz clock instead of a possible 230.4 MHz clock. This series proposes setting the clock rate. Patch 2 is the "safe" approach where a platform must handle it, patch 3 is the big hammer where we max out the clock for all users. I think patch 2 is using a proper callback (I want to document those a bit in the future to make it easier for future folks using them). My guess is that doing this driver wide might be undesirable for some reasons I'm not aware of (right now I blindly request the max frequency but the IP could have an upper limit here, platform maintainers maybe upset if their careful validation at prior frequencies changes, etc). I've only tested that the Qualcomm boards I have access to in a remote lab still work (i.e. throughput testing, etc) and that the PTP programming is now what I expected it to be theoretically. I'd really appreciate someone with the ability (and know how!) to test PTP tried this on at least the Qualcomm platforms. Bonus points if someone explains how one would even test PTP networks like this. Thanks, Andrew Andrew Halaney (3): net: stmmac: Make ptp_clk_freq_config variable type explicit net: stmmac: dwmac-qcom-ethqos: Use max frequency for clk_ptp_ref net: stmmac: Use the max frequency possible for clk_ptp_ref .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 3 +-- .../stmicro/stmmac/dwmac-qcom-ethqos.c | 18 ++++++++++++++++++ .../ethernet/stmicro/stmmac/stmmac_platform.c | 5 +++++ include/linux/stmmac.h | 4 +++- 4 files changed, 27 insertions(+), 3 deletions(-)