[PATCH 4/5] arm64: dts: allwinner: a527: add EMAC0 to Radxa A5E board
Andrew Lunn
andrew at lunn.ch
Thu Apr 24 05:57:27 PDT 2025
> > Just to be clear, you tried it with "rgmii-id" and the same <300> and
> > <400> values?
>
> Yes, sorry, I wasn't clear: I used rgmii-id, then experimented with those
> values.
O.K, great.
I do suspect the delays are not actually in pico seconds. But without
a data sheet, it is hard to know.
if (!of_property_read_u32(node, "allwinner,rx-delay-ps", &val)) {
if (val % 100) {
dev_err(dev, "rx-delay must be a multiple of 100\n");
return -EINVAL;
}
val /= 100;
dev_dbg(dev, "set rx-delay to %x\n", val);
if (val <= gmac->variant->rx_delay_max) {
reg &= ~(gmac->variant->rx_delay_max <<
SYSCON_ERXDC_SHIFT);
reg |= (val << SYSCON_ERXDC_SHIFT);
So the code divides by 100 and writes it to a register. But:
static const struct emac_variant emac_variant_h3 = {
.rx_delay_max = 31,
static const struct emac_variant emac_variant_r40 = {
.rx_delay_max = 7,
};
With the change from 7 to 31, did the range get extended by a factor
of 4, or did the step go down by a factor of 4, and the / 100 should
be / 25? I suppose the git history might have the answer in the commit
message, but i'm too lazy to go look.
Andrew
I briefly tried "rgmii", and I couldn't get a lease, so I quite
> confident it's rgmii-id, as you said. The vendor DTs just use "rgmii", but
> they might hack the delay up another way (and I cannot be asked to look at
> that awful code).
>
> Cheers,
> Andre
More information about the linux-arm-kernel
mailing list