[PATCH RFC] ARM: dts: add support for Turris Omnia
tomas.hlavacek at nic.cz
tomas.hlavacek at nic.cz
Wed Nov 23 14:45:20 PST 2016
Hi Andrew!
On Wed, Nov 23, 2016 at 3:59 PM, Andrew Lunn <andrew at lunn.ch> wrote:
>> >CZ11NIC12 is indicated on my board.
>>
>> :-( Well, this board version has wrongly matched length of some
>> differential pairs, IRQ from 88E1514 is connected differently, there
>> are slight differences in power supplies and (if I am not mistaken)
>> something changed in RTC support circuitry. It looks like a huge
>> mistake on our side.
>
> Hi Tomas
>
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?
I do not think so. The ethernet links to the switch are RGMII, not
differential pairs. Differential pair is used only for the eth2 to link
either SFP+ or 88E1514 (via a high-speed switch that selects one or
another). So the problems with differential pairs affect only WAN
interface.
>
>
>> It seems that libphy is probed before pca9538 and we end up with:
>> [ 4.217550] libphy: orion_mdio_bus: probed
>> [ 4.221777] irq: no irq domain found for
>> /soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !
>>
>> Any clue where to look in order to defer probing libphy or at least
>> orion_mdio_bus?
>
> I think there is a known phylib problem here. Somewhere in the call
> chain there is a void function, so the EPROBE_DEFFER gets
> discarded. But i could be remembering this wrongly.
Oh yes, I thought that and I tried to find exactly this type of problem
yesterday, but I didn't succeed. But I think that we agreed that we are
going to stick with PHY polling rather then experimenting with
unreliable IRQ over the GPIO expander, so we can leave this unresolved.
I will look into the I2C mux concerns, fix the remaining comments
regarding my version and test RTC more extensively - Uwe's board is
still not ticking, mine does, so we have to rule out that it is a
common problem.
Tomas
More information about the linux-arm-kernel
mailing list