mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Luo Jie <quic_luoj@quicinc.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Lei Wei <quic_leiwei@quicinc.com>,
	Suruchi Agarwal <quic_suruchia@quicinc.com>,
	Pavithra R <quic_pavir@quicinc.com>,
	Simon Horman <horms@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Kees Cook <kees@kernel.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-arm-msm@vger.kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-hardening@vger.kernel.org,
	quic_kkumarcs@quicinc.com, quic_linchen@quicinc.com
Subject: Re: [PATCH net-next v5 03/14] net: ethernet: qualcomm: Add PPE driver for IPQ9574 SoC
Date: Wed, 30 Jul 2025 13:57:03 +0200	[thread overview]
Message-ID: <4e9ec735-1278-4475-8898-1e12ccb94909@oss.qualcomm.com> (raw)
In-Reply-To: <e768d295-843c-431d-b439-e2ed07de638e@quicinc.com>

On 7/1/25 2:24 PM, Luo Jie wrote:
> 
> 
> On 6/28/2025 12:21 AM, Konrad Dybcio wrote:
>> On 6/26/25 4:31 PM, Luo Jie wrote:
>>> The PPE (Packet Process Engine) hardware block is available on Qualcomm
>>> IPQ SoC that support PPE architecture, such as IPQ9574.
>>>
>>> The PPE in IPQ9574 includes six integrated ethernet MAC for 6 PPE ports,
>>> buffer management, queue management and scheduler functions. The MACs
>>> can connect with the external PHY or switch devices using the UNIPHY PCS
>>> block available in the SoC.
>>>
>>> The PPE also includes various packet processing offload capabilities
>>> such as L3 routing and L2 bridging, VLAN and tunnel processing offload.
>>> It also includes Ethernet DMA function for transferring packets between
>>> ARM cores and PPE ethernet ports.
>>>
>>> This patch adds the base source files and Makefiles for the PPE driver
>>> such as platform driver registration, clock initialization, and PPE
>>> reset routines.
>>>
>>> Signed-off-by: Luo Jie <quic_luoj@quicinc.com>
>>> ---
>>
>> [...]
>>
>>> +static int ppe_clock_init_and_reset(struct ppe_device *ppe_dev)
>>> +{
>>> +    unsigned long ppe_rate = ppe_dev->clk_rate;
>>> +    struct device *dev = ppe_dev->dev;
>>> +    struct reset_control *rstc;
>>> +    struct clk_bulk_data *clks;
>>> +    struct clk *clk;
>>> +    int ret, i;
>>> +
>>> +    for (i = 0; i < ppe_dev->num_icc_paths; i++) {
>>> +        ppe_dev->icc_paths[i].name = ppe_icc_data[i].name;
>>> +        ppe_dev->icc_paths[i].avg_bw = ppe_icc_data[i].avg_bw ? :
>>> +                           Bps_to_icc(ppe_rate);
>>> +        ppe_dev->icc_paths[i].peak_bw = ppe_icc_data[i].peak_bw ? :
>>> +                        Bps_to_icc(ppe_rate);
>>> +    }
>>
>> Can you not just set ppe_dev->icc_paths to ppe_icc_data?
>>
>> Konrad
> 
> The `avg_bw` and `peak_bw` for two of the PPE ICC clocks ('ppe' and
> 'ppe_cfg') vary across different SoCs and they need to be read from
> platform data. They are not pre-defined in `ppe_icc_data` array.
> Therefore, we use this format to assign `icc_paths`, allowing us to
> accommodate cases where `avg_bw` and `peak_bw` are not predefined.
> Hope this is fine. Thanks.

You're currently hardcoding the clock rate, which one of the comments
suggests is where the bw values come from. Is there a formula that we
could calculate the necessary bandwidth based on?

We could then clk_get_rate() and do it dynamically

Konrad

  reply	other threads:[~2025-07-30 11:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-26 14:30 [PATCH net-next v5 00/14] Add PPE driver for Qualcomm " Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 01/14] dt-bindings: net: Add PPE " Luo Jie
2025-07-01  7:11   ` Krzysztof Kozlowski
2025-07-03  9:36     ` Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 02/14] docs: networking: Add PPE driver documentation " Luo Jie
2025-06-26 22:02   ` Randy Dunlap
2025-06-27 13:09     ` Lei Wei
2025-06-26 14:31 ` [PATCH net-next v5 03/14] net: ethernet: qualcomm: Add PPE driver for " Luo Jie
2025-06-27 16:21   ` Konrad Dybcio
2025-07-01 12:24     ` Luo Jie
2025-07-30 11:57       ` Konrad Dybcio [this message]
2025-08-01 14:42         ` Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 04/14] net: ethernet: qualcomm: Initialize PPE buffer management for IPQ9574 Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 05/14] net: ethernet: qualcomm: Initialize PPE queue " Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 06/14] net: ethernet: qualcomm: Initialize the PPE scheduler settings Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 07/14] net: ethernet: qualcomm: Initialize PPE queue settings Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 08/14] net: ethernet: qualcomm: Initialize PPE service code settings Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 09/14] net: ethernet: qualcomm: Initialize PPE port control settings Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 10/14] net: ethernet: qualcomm: Initialize PPE RSS hash settings Luo Jie
2025-07-17 20:48   ` Konrad Dybcio
2025-07-18  7:41     ` Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 11/14] net: ethernet: qualcomm: Initialize PPE queue to Ethernet DMA ring mapping Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 12/14] net: ethernet: qualcomm: Initialize PPE L2 bridge settings Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 13/14] net: ethernet: qualcomm: Add PPE debugfs support for PPE counters Luo Jie
2025-06-26 14:31 ` [PATCH net-next v5 14/14] MAINTAINERS: Add maintainer for Qualcomm PPE driver Luo Jie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4e9ec735-1278-4475-8898-1e12ccb94909@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=gustavoars@kernel.org \
    --cc=horms@kernel.org \
    --cc=kees@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=quic_kkumarcs@quicinc.com \
    --cc=quic_leiwei@quicinc.com \
    --cc=quic_linchen@quicinc.com \
    --cc=quic_luoj@quicinc.com \
    --cc=quic_pavir@quicinc.com \
    --cc=quic_suruchia@quicinc.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®