> On Mon, Jun 24, 2024 at 01:55:10AM +0200, Lorenzo Bianconi wrote:
> > > > +static int airoha_fe_set_pse_oq_rsv(struct airoha_eth *eth,
> > > > + u32 port, u32 queue, u32 val)
> > > > +{
> > > > + u32 orig_val, tmp, all_rsv, fq_limit;
> > > > + const u32 pse_port_oq_id[] = {
> > > > + PSE_PORT0_QUEUE,
> > > > + PSE_PORT1_QUEUE,
> > > > + PSE_PORT2_QUEUE,
> > > > + PSE_PORT3_QUEUE,
> > > > + PSE_PORT4_QUEUE,
> > > > + PSE_PORT5_QUEUE,
> > > > + PSE_PORT6_QUEUE,
> > > > + PSE_PORT7_QUEUE,
> > > > + PSE_PORT8_QUEUE,
> > > > + PSE_PORT9_QUEUE,
> > > > + PSE_PORT10_QUEUE
> > > > + };
> > >
> > > > +static void airoha_fe_oq_rsv_init(struct airoha_eth *eth)
> > > > +{
> > > > + int i;
> > > > +
> > > > + /* hw misses PPE2 oq rsv */
> > > > + airoha_fe_set(eth, REG_FE_PSE_BUF_SET,
> > > > + PSE_DEF_RSV_PAGE * PSE_PORT8_QUEUE);
> > > > +
> > > > + for (i = 0; i < PSE_PORT0_QUEUE; i++)
> > > > + airoha_fe_set_pse_oq_rsv(eth, 0, i, 0x40);
> > > > + for (i = 0; i < PSE_PORT1_QUEUE; i++)
> > > > + airoha_fe_set_pse_oq_rsv(eth, 1, i, 0x40);
> > > > +
> > > > + for (i = 6; i < PSE_PORT2_QUEUE; i++)
> > > > + airoha_fe_set_pse_oq_rsv(eth, 2, i, 0);
> > > > +
> > > > + for (i = 0; i < PSE_PORT3_QUEUE; i++)
> > > > + airoha_fe_set_pse_oq_rsv(eth, 3, i, 0x40);
> > >
> > > Code like this is making me wounder about the split between MAC
> > > driver, DSA driver and DSA tag driver. Or if it should actually be a
> > > pure switchdev driver?
> >
> > airoha_eth driver implements just MAC features (FE and QDMA). Currently we only
> > support the connection to the DSA switch (GDM1). EN7581 SoC relies on mt7530 driver
> > for DSA (I have not posted the patch for mt7530 yet, I will do after airoha_eth
> > ones).
>
> > airoha_fe_oq_rsv_init() (we can improve naming here :) is supposed to configure
> > hw pre-allocated memory for each queue available in Packet Switching Engine
> > (PSE) ports. PSE ports are not switch ports, but SoC internal ports used to
> > connect PSE to different modules. In particular, we are currently implementing
> > just the two connections below:
> > - CDM1 (port0) connects PSE to QDMA1
> > - GDM1 (port1) connects PSE to MT7530 DSA switch
> >
> > In the future we will post support for GDM2, GDM3 and GDM4 ports that are
> > connecting PSE to exteranl PHY modules.
>
> Is the PSE involved in WiFi? When you come to implement NAT offload,
> etc, will that depend on the PSE?
>
Frame Engine architecture (Packet Switching Engine - PSE + Packet Processing
Engine - PPE) is similar to mtk_eth_soc driver (but register map and QDMA layer
are different). FE is used to define offload traffic rules (e.g. forwarding
between GDM interfaces or NAT rules). Even in mtk_eth_soc frame engine codebase
is part of MAC driver. So far we do not support offloading rules, but we will
do in the future. In order to support WiFI offload rules, FE requires a different
module/driver (NPU) similar to WED for mtk_eth_soc.
The mac - switch architecture is the same to the one used for MT7988a [0].
So far we support we support just gmac0 (that is connected to the switch).
In the future I will add support for gmac1 as well.
Regards,
Lorenzo
[0] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a.dtsi;h=9ad068fe05fc52bf1edc28d7dba4e162f30a0eb8;hb=HEAD
> Figure 9-1 of MT7981B_Wi-Fi6_Platform_Datasheet_Open_V1.0.pdf clearly
> shows the PSE outside of the GMAC. I'm just wondering if the PSE
> should be a driver, or library, of its own, which is then shared by
> users, rather than being embedded in the MAC driver?
>
> Andrew
Attachment:
signature.asc
Description: PGP signature
