[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e768d295-843c-431d-b439-e2ed07de638e@quicinc.com>
Date: Tue, 1 Jul 2025 20:24:49 +0800
From: Luo Jie <quic_luoj@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Andrew Lunn
<andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
"Eric
Dumazet" <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski
<krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Lei Wei
<quic_leiwei@...cinc.com>,
Suruchi Agarwal <quic_suruchia@...cinc.com>,
Pavithra R <quic_pavir@...cinc.com>, Simon Horman <horms@...nel.org>,
Jonathan Corbet <corbet@....net>, Kees Cook <kees@...nel.org>,
"Gustavo A. R.
Silva" <gustavoars@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>
CC: <linux-arm-msm@...r.kernel.org>, <netdev@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <linux-hardening@...r.kernel.org>,
<quic_kkumarcs@...cinc.com>, <quic_linchen@...cinc.com>
Subject: Re: [PATCH net-next v5 03/14] net: ethernet: qualcomm: Add PPE driver
for IPQ9574 SoC
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@...cinc.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.
Powered by blists - more mailing lists