Re: [PATCH 4/5] arm64: dts: allwinner: a527: add EMAC0 to Radxa A5E board

[Andrew Lunn <andrew@lunn.ch>]

> > 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