mbox series

[net-next,00/20] net: ethernet: Add qcom PPE driver

Message ID 20240110114033.32575-1-quic_luoj@quicinc.com (mailing list archive)
Headers show
Series net: ethernet: Add qcom PPE driver | expand

Message

Jie Luo Jan. 10, 2024, 11:40 a.m. UTC
The PPE(packet process engine) hardware block is available in Qualcomm
IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.
The PPE includes integrated ethernet MAC and PCS(uniphy), which is used
to connect with external PHY devices by PCS. The PPE also includes
various packet processing offload capabilities such as routing and
briding offload, L2 switch capability, VLAN and tunnel processing
offload.

This patch series enables support for the PPE driver which intializes
and configures the PPE, and provides various services for higher level
network drivers in the system such as EDMA (Ethernet DMA) driver or a
DSA switch driver for PPE L2 Switch, for Qualcomm IPQ SoCs.

The PPE driver provides following functions:

1. Initialize PPE device hardware functions such as buffer management,
   queue management, TDM, scheduler and clocks in order to bring up PPE
   device.

2. Register the PCS driver and uniphy raw clock provider. The uniphy
   raw clock is selected as the parent clock of the NSSCC clocks. The
   NSSCC clocks are registered by the dependent patchset at the link
   below.(Note: There are 3 PCS on IPQ9574, 2 PCS on IPQ5332 platform.)

3. Export the PPE control path API (ppe_device_ops) for use by higher
   level network drivers such as  the EDMA(Ethernet DMA) driver. The
   EDMA netdevice driver depends on this PPE driver and  registers the
   netdevices to receive and transmit packets using the ethernet ports.

4. Register debugfs file to provide access to various PPE packet counters.
   These statistics are recorded by the various HW counters, such as port
   RX/TX, CPU code and HW queue counters.

The diagram and detail introduction of PPE are described in the added file:
Documentation/networking/device_drivers/ethernet/qualcomm/ppe/ppe.rst,
which is added by the first patch.
<Documentation: networking: qcom PPE driver documentation>.

PPE driver depends on the NSSCC clock driver below, which provides the
clocks for the PPE driver.
https://lore.kernel.org/linux-arm-msm/20230825091234.32713-1-quic_devipriy@quicinc.com/
https://lore.kernel.org/linux-arm-msm/20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com/

PPE driver also depens on the device tree patch series to bring up PPE
device as below link.
https://lore.kernel.org/all/20240110112059.2498-1-quic_luoj@quicinc.com/

Lei Wei (5):
  Documentation: networking: qcom PPE driver documentation
  net: ethernet: qualcomm: Add PPE L2 bridge initialization
  net: ethernet: qualcomm: Add PPE UNIPHY support for phylink
  net: ethernet: qualcomm: Add PPE MAC support for phylink
  net: ethernet: qualcomm: Add PPE MAC functions

Luo Jie (15):
  dt-bindings: net: qcom,ppe: Add bindings yaml file
  net: ethernet: qualcomm: Add qcom PPE driver
  net: ethernet: qualcomm: Add PPE buffer manager configuration
  net: ethernet: qualcomm: Add PPE queue management config
  net: ethernet: qualcomm: Add PPE TDM config
  net: ethernet: qualcomm: Add PPE port scheduler resource
  net: ethernet: qualcomm: Add PPE scheduler config
  net: ethernet: qualcomm: Add PPE queue config
  net: ethernet: qualcomm: Add PPE service code config
  net: ethernet: qualcomm: Add PPE port control config
  net: ethernet: qualcomm: Add PPE RSS hash config
  net: ethernet: qualcomm: Export PPE function set_maxframe
  net: ethernet: qualcomm: Add PPE AC(admission control) function
  net: ethernet: qualcomm: Add PPE debugfs counters
  arm64: defconfig: Enable qcom PPE driver

 .../devicetree/bindings/net/qcom,ppe.yaml     | 1330 +++++++
 .../device_drivers/ethernet/index.rst         |    1 +
 .../ethernet/qualcomm/ppe/ppe.rst             |  305 ++
 MAINTAINERS                                   |    9 +
 arch/arm64/configs/defconfig                  |    1 +
 drivers/net/ethernet/qualcomm/Kconfig         |   17 +
 drivers/net/ethernet/qualcomm/Makefile        |    1 +
 drivers/net/ethernet/qualcomm/ppe/Makefile    |    7 +
 drivers/net/ethernet/qualcomm/ppe/ppe.c       | 3070 +++++++++++++++++
 drivers/net/ethernet/qualcomm/ppe/ppe.h       |  315 ++
 .../net/ethernet/qualcomm/ppe/ppe_debugfs.c   |  953 +++++
 .../net/ethernet/qualcomm/ppe/ppe_debugfs.h   |   25 +
 drivers/net/ethernet/qualcomm/ppe/ppe_ops.c   |  628 ++++
 drivers/net/ethernet/qualcomm/ppe/ppe_ops.h   |  256 ++
 drivers/net/ethernet/qualcomm/ppe/ppe_regs.h  | 1106 ++++++
 .../net/ethernet/qualcomm/ppe/ppe_uniphy.c    |  789 +++++
 .../net/ethernet/qualcomm/ppe/ppe_uniphy.h    |  227 ++
 include/linux/soc/qcom/ppe.h                  |  105 +
 18 files changed, 9145 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/qcom,ppe.yaml
 create mode 100644 Documentation/networking/device_drivers/ethernet/qualcomm/ppe/ppe.rst
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/Makefile
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe.c
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe.h
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe_debugfs.c
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe_debugfs.h
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe_ops.c
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe_ops.h
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe_regs.h
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe_uniphy.c
 create mode 100644 drivers/net/ethernet/qualcomm/ppe/ppe_uniphy.h
 create mode 100644 include/linux/soc/qcom/ppe.h


base-commit: a7fe0881d9b78d402bbd9067dd4503a57c57a1d9

Comments

Krzysztof Kozlowski Jan. 10, 2024, 12:24 p.m. UTC | #1
On 10/01/2024 12:40, Luo Jie wrote:
> The PPE(packet process engine) hardware block is available in Qualcomm
> IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.
> The PPE includes integrated ethernet MAC and PCS(uniphy), which is used
> to connect with external PHY devices by PCS. The PPE also includes
> various packet processing offload capabilities such as routing and
> briding offload, L2 switch capability, VLAN and tunnel processing
> offload.
> 
> This patch series enables support for the PPE driver which intializes
> and configures the PPE, and provides various services for higher level
> network drivers in the system such as EDMA (Ethernet DMA) driver or a
> DSA switch driver for PPE L2 Switch, for Qualcomm IPQ SoCs.

net-next is closed.

Best regards,
Krzysztof
Simon Horman Jan. 10, 2024, 3:44 p.m. UTC | #2
On Wed, Jan 10, 2024 at 01:24:06PM +0100, Krzysztof Kozlowski wrote:
> On 10/01/2024 12:40, Luo Jie wrote:
> > The PPE(packet process engine) hardware block is available in Qualcomm
> > IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.
> > The PPE includes integrated ethernet MAC and PCS(uniphy), which is used
> > to connect with external PHY devices by PCS. The PPE also includes
> > various packet processing offload capabilities such as routing and
> > briding offload, L2 switch capability, VLAN and tunnel processing
> > offload.
> > 
> > This patch series enables support for the PPE driver which intializes
> > and configures the PPE, and provides various services for higher level
> > network drivers in the system such as EDMA (Ethernet DMA) driver or a
> > DSA switch driver for PPE L2 Switch, for Qualcomm IPQ SoCs.
> 
> net-next is closed.

Also, please try to avoid sending patch-sets with more than 15 patches
for net or net-next.

https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#dividing-work-into-patches
Jakub Kicinski Jan. 10, 2024, 10:24 p.m. UTC | #3
On Wed, 10 Jan 2024 19:40:12 +0800 Luo Jie wrote:
> The PPE(packet process engine) hardware block is available in Qualcomm
> IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.

What's the relationship between this driver and QCA8084?

In the last month I see separate changes from you for mdio-ipq4019.c,
phy/at803x.c and now this driver (none of which got merged, AFAICT.)
Are you actually the author of this code, or are you just trying 
to upstream bunch of vendor code?

Now you're dumping another 10kLoC on the list, and even though this is
hardly your first posting you're apparently not aware of our most basic
posting rules:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr

The reviewers are getting frustrated. Please, help us help you.
Stop throwing code at the list and work out a plan with Andrew
and others on how to get something merged...
Jie Luo Jan. 11, 2024, 3:49 p.m. UTC | #4
On 1/11/2024 6:24 AM, Jakub Kicinski wrote:
> On Wed, 10 Jan 2024 19:40:12 +0800 Luo Jie wrote:
>> The PPE(packet process engine) hardware block is available in Qualcomm
>> IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.
> 
> What's the relationship between this driver and QCA8084?

The PPE (packet processing engine) is the network processing hardware 
block in QCOM IPQ SoC. It includes the ethernet MAC and UNIPHY(PCS). 
This driver is the base PPE driver which brings up the PPE and handles 
MAC/UNIPHY operations. QCA8084 is the external 2.5Gbps 4-port PHY 
device, which can be connected with PPE integrated MAC by UNIPHY(PCS).

Here is the relationship.
PPE integrated MAC --- PPE integrated UNIPHY(PCS) --- (PCS)QCA8084.

> 
> In the last month I see separate changes from you for mdio-ipq4019.c,
> phy/at803x.c and now this driver (none of which got merged, AFAICT.)
> Are you actually the author of this code, or are you just trying
> to upstream bunch of vendor code?

Yes, Jakub, there are two authors in these patch series, Lei Wei and me.
The patches are already ready for some time, the code has been verified
on the Qualcomm reference design board. These are not downstream drivers
but drivers re-written for upstream.

> 
> Now you're dumping another 10kLoC on the list, and even though this is
> hardly your first posting you're apparently not aware of our most basic
> posting rules:
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
> 
> The reviewers are getting frustrated. Please, help us help you.
> Stop throwing code at the list and work out a plan with Andrew
> and others on how to get something merged...

Sorry for trouble caused, will learn about the guidance provided by
the review comments, and follow up on the guidance and have the full
internal review of the patch updates before pushing the patch series.
Jie Luo Jan. 12, 2024, 3:49 p.m. UTC | #5
On 1/10/2024 11:44 PM, Simon Horman wrote:
> On Wed, Jan 10, 2024 at 01:24:06PM +0100, Krzysztof Kozlowski wrote:
>> On 10/01/2024 12:40, Luo Jie wrote:
>>> The PPE(packet process engine) hardware block is available in Qualcomm
>>> IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.
>>> The PPE includes integrated ethernet MAC and PCS(uniphy), which is used
>>> to connect with external PHY devices by PCS. The PPE also includes
>>> various packet processing offload capabilities such as routing and
>>> briding offload, L2 switch capability, VLAN and tunnel processing
>>> offload.
>>>
>>> This patch series enables support for the PPE driver which intializes
>>> and configures the PPE, and provides various services for higher level
>>> network drivers in the system such as EDMA (Ethernet DMA) driver or a
>>> DSA switch driver for PPE L2 Switch, for Qualcomm IPQ SoCs.
>>
>> net-next is closed.
> 
> Also, please try to avoid sending patch-sets with more than 15 patches
> for net or net-next.
> 
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#dividing-work-into-patches

Got it, at a later point when this review resumes, we will split the PPE 
driver patches into two series, one is for PPE switch core feature, 
another is for MAC/UNIPHY features. Hope this is fine.

Thanks for this comment.
Christian Marangi Jan. 12, 2024, 5:56 p.m. UTC | #6
On Thu, Jan 11, 2024 at 11:49:53PM +0800, Jie Luo wrote:
> 
> 
> On 1/11/2024 6:24 AM, Jakub Kicinski wrote:
> > On Wed, 10 Jan 2024 19:40:12 +0800 Luo Jie wrote:
> > > The PPE(packet process engine) hardware block is available in Qualcomm
> > > IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.
> > 
> > What's the relationship between this driver and QCA8084?
> 
> The PPE (packet processing engine) is the network processing hardware block
> in QCOM IPQ SoC. It includes the ethernet MAC and UNIPHY(PCS). This driver
> is the base PPE driver which brings up the PPE and handles MAC/UNIPHY
> operations. QCA8084 is the external 2.5Gbps 4-port PHY device, which can be
> connected with PPE integrated MAC by UNIPHY(PCS).
> 
> Here is the relationship.
> PPE integrated MAC --- PPE integrated UNIPHY(PCS) --- (PCS)QCA8084.
> 
> > 
> > In the last month I see separate changes from you for mdio-ipq4019.c,
> > phy/at803x.c and now this driver (none of which got merged, AFAICT.)
> > Are you actually the author of this code, or are you just trying
> > to upstream bunch of vendor code?
> 
> Yes, Jakub, there are two authors in these patch series, Lei Wei and me.
> The patches are already ready for some time, the code has been verified
> on the Qualcomm reference design board. These are not downstream drivers
> but drivers re-written for upstream.
> 
> > 
> > Now you're dumping another 10kLoC on the list, and even though this is
> > hardly your first posting you're apparently not aware of our most basic
> > posting rules:
> > https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
> > 
> > The reviewers are getting frustrated. Please, help us help you.
> > Stop throwing code at the list and work out a plan with Andrew
> > and others on how to get something merged...
> 
> Sorry for trouble caused, will learn about the guidance provided by
> the review comments, and follow up on the guidance and have the full
> internal review of the patch updates before pushing the patch series.

I renew my will of helping in any kind of manner in this, I love the
intention for EDMAv2 to have an upstream driver instead of SSDK, hoping
in the future to also have the same treatement for EDMAv1 (it's really a
pitty to have a support hole with ipq807x not supported)

Feel free to send an email or anything, considering this is massive, an
extra eye before sending might make things better than reaching (I can
already see this) a massive series with at least 20 revision given the
complexity of this thing.
Jie Luo Jan. 17, 2024, 3:25 p.m. UTC | #7
On 1/13/2024 1:56 AM, Christian Marangi wrote:
> On Thu, Jan 11, 2024 at 11:49:53PM +0800, Jie Luo wrote:
>>
>>
>> On 1/11/2024 6:24 AM, Jakub Kicinski wrote:
>>> On Wed, 10 Jan 2024 19:40:12 +0800 Luo Jie wrote:
>>>> The PPE(packet process engine) hardware block is available in Qualcomm
>>>> IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.
>>>
>>> What's the relationship between this driver and QCA8084?
>>
>> The PPE (packet processing engine) is the network processing hardware block
>> in QCOM IPQ SoC. It includes the ethernet MAC and UNIPHY(PCS). This driver
>> is the base PPE driver which brings up the PPE and handles MAC/UNIPHY
>> operations. QCA8084 is the external 2.5Gbps 4-port PHY device, which can be
>> connected with PPE integrated MAC by UNIPHY(PCS).
>>
>> Here is the relationship.
>> PPE integrated MAC --- PPE integrated UNIPHY(PCS) --- (PCS)QCA8084.
>>
>>>
>>> In the last month I see separate changes from you for mdio-ipq4019.c,
>>> phy/at803x.c and now this driver (none of which got merged, AFAICT.)
>>> Are you actually the author of this code, or are you just trying
>>> to upstream bunch of vendor code?
>>
>> Yes, Jakub, there are two authors in these patch series, Lei Wei and me.
>> The patches are already ready for some time, the code has been verified
>> on the Qualcomm reference design board. These are not downstream drivers
>> but drivers re-written for upstream.
>>
>>>
>>> Now you're dumping another 10kLoC on the list, and even though this is
>>> hardly your first posting you're apparently not aware of our most basic
>>> posting rules:
>>> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
>>>
>>> The reviewers are getting frustrated. Please, help us help you.
>>> Stop throwing code at the list and work out a plan with Andrew
>>> and others on how to get something merged...
>>
>> Sorry for trouble caused, will learn about the guidance provided by
>> the review comments, and follow up on the guidance and have the full
>> internal review of the patch updates before pushing the patch series.
> 
> I renew my will of helping in any kind of manner in this, I love the
> intention for EDMAv2 to have an upstream driver instead of SSDK, hoping
> in the future to also have the same treatement for EDMAv1 (it's really a
> pitty to have a support hole with ipq807x not supported)
> 
> Feel free to send an email or anything, considering this is massive, an
> extra eye before sending might make things better than reaching (I can
> already see this) a massive series with at least 20 revision given the
> complexity of this thing.
> 

Thanks Christian for the help. Yes, the EDMAV2 driver will be posted 
some time after net-next is reopen and after this PPE driver patch 
series resumes. The EDMAv2 driver will be posted as separate driver 
series, which depends on this PPE driver. Currently we plan to post the 
EDMAv2 driver support for IPQ5332 and IPQ9574 firstly. For IPQ807x, it 
is a driver for an older architecture as you can see, but we will 
consider this for the future.

We will certainly review it internally before publishing it later for 
upstream review.