回覆: [PATCH 0/5] net: ftgmac100: Add AST2700 support

[Jacky Chou]

Hi Andrew,

Thank you for your reply.

> > AST2700 keeps using the FTGMAC100 MAC IP, but the enablement is not
> > limited to a new compatible string. The SoC can boot with the MAC on
> > ARM64, needs the Aspeed-specific RMII mode bit programmed when a port
> > is wired for RMII, and requires the driver to use the upper DMA
> > address fields in the ring base registers and packet descriptors.
> > Those fields expose a 35-bit DMA address range on AST2700, so the
> > driver must request a mask that matches the address bits the hardware can
> encode.
> >
> > The series first documents and wires up the aspeed,ast2700-mac
> > compatible. It then treats AST2700 as an Aspeed MAC in the driver,
> > enables the RMII mode programming, writes the AST2700 high
> > descriptor-ring base registers, carries the RX/TX descriptor high
> > address bits, rebuilds full DMA addresses before unmapping buffers,
> > and requests a 35-bit DMA mask. The high ring base registers are only
> > touched for AST2700 so older Aspeed device tree register windows
> > remain unchanged. With that in place, the FTGMAC100 Kconfig entry can
> > be made available on ARM64 while keeping the existing Aspeed MDIO
> > dependency for AST2600 and newer ARCH_ASPEED systems.
> 
> There is no mention of RGMII here or RGMII delays. Given the mess that the
> AST2600 is, i would expect to see some explanation how that has been solved.
> 

Currently, we provide our custom or user to configure RGMII delay in bootloader stage,
it is the same as AST2600 in bootloader. So, when booting to kernel, the RGMII delay will
be kept. The ftgmac100 driver with AST2600 and the next generation AST2700 does not
need to configure the RGMII delay.
I will add more descriptions about the RGMII delay configuration in this first mail in next
version.

Thanks,
Jacky