On Thu, Jan 25, 2018 at 12:21:07AM +0000, André Przywara wrote:
On 23/01/18 22:46, Kyle Evans wrote:
On Tue, Jan 23, 2018 at 4:18 PM, Samuel Holland samuel@sholland.org wrote:
These nodes were previously in an unused file specific to the Pine64. Move them to the base SoC device tree for use by other boards. Require individual boards to enable the emac and provide a pin configuration.
Signed-off-by: Samuel Holland samuel@sholland.org
arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 50 ------------------------- arch/arm/dts/sun50i-a64.dtsi | 28 ++++++++++++++ 2 files changed, 28 insertions(+), 50 deletions(-) delete mode 100644 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
On that note, it seems like it would be a good idea to re-sync this with mainline Linux now that emac bindings exist in-tree [1] and these are generally becoming standard. Thoughts?
Sure. The problem with that is that the Ethernet nodes are no longer compatible with what the U-Boot driver understands. Solutions are:
- Keep the EMAC nodes - in "old" U-Boot style - in a *-u-boot.dtsi
override. Easy enough, but bad idea.
- Teach the U-Boot EMAC driver to cope with the new bindings. I sent
patches for that a while ago [2]. Problem is that people didn't like the "handish" way of parsing the pinctrl properties - instead opting for a proper DM pinctrl driver for sunxi. Sounds reasonable - but is a quite a chunk of work. This was on the list before - but IMHO a bit over the top by copying the Linux driver.
I was wondering if we could just go with the easy pinctrl solution (as in [2], based on what we currently have in the EMAC driver). We could switch anytime to a proper DM pinctrl driver - which is on my list, but not very high on it. I have some ideas on how to make this small and simple, as we don't need the fully glory and bloat of the Linux driver.
If people are OK with this, I can post a rebased version of [2]. We can then just copy the mainline DTs for A64 into U-Boot. And leave the DM pinctrl driver for another time.
That's what I was about to suggest. The pinctrl discussion is pretty much orthogonal, and we'll have to convert a whole bunch of drivers anyway when that happens, so it's not a big deal to add a new driver that doesn't rely on pinctrl at the moment.
Maxime