On Fri, Apr 08, 2016 at 03:30:24PM +0200, Mark Kettenis wrote:
> > Date: Fri, 8 Apr 2016 14:53:35 +0200
> > From: Patrick Wildt <[email protected]>
> >
> > On Fri, Apr 08, 2016 at 03:29:05PM +0300, Artturi Alm wrote:
> > > On Fri, Apr 08, 2016 at 01:44:11PM +0200, Patrick Wildt wrote:
> > > > Hi,
> > > >
> > > > with the feedback received on the fdt bus, the fdt stuff will now be
> > > > replacing the mainbus. [..snip..]
> > > >
> > > > Patrick
> > > >
> > > > [..snip..]
> > >
> > > Hi,
> > >
> > > have you planned ahead which route you are going to take with regards to
> > > how drivers will be written in the future? i see two options, do it all
> > > in some kind of mainbus(per soc?) and feed driver _attach() args(i'd
> > > prefer),
> > > or infest all of the drivers with fdt node lookups and linux/fbsd-like
> > > code/logic.
> > >
> > > i think it's a design question that all of you should agree upon as early
> > > as
> > > possible to avoid cruft. as a result of my own incompetence i have
> > > rewritten
> > > each and every armv7 driver xxx_match() a few times. ;D
> > >
> > > -Artturi
> > >
> >
> > The idea is that all drivers attach to mainbus. The driver checks its
> > mainbus_attach_args in the match function, if the given node is
> > compatible to the driver, by doing something simple like:
> >
> > if (fdt_node_compatible(ma->ma_node, "samsung,exynos4210-ehci"))
> > return (1);
> >
> > When it attaches, it's given a node, a bus space and bus dma tag. This
> > is all it needs to do its job. I hope that soon we can have some
> > FDT-based API to attach interrupts:
> >
> > arm_intr_establish_fdt(ma->ma_node, IPL_NET, handler, sc,
> > sc->sc_dev.dv_xname);
> >
> > Similarly, we should have something for Clocks and GPIOs. Those are all
> > exposed in the device tree which we can make plenty use of.
> >
> > There are a few drivers that need special handling. EHCI and AHCI need
> > an attachment driver, as ehci* at mainbus? can only be handled by one
> > driver. So you need something like.
> >
> > imxehci* at mainbus?
> > ehci* at imxehci?
> >
> > That's a bit of an overhead and steals about 16 lines in
> > imxehci.c/imxahci.c.
> >
> > You don't anymore need an imx0, exynos0 or sunxi0 bus. Those can all be
> > replaced by the mainbus.
>
> Actually, I don't think that's the right approach either. The FDT is
> a device tree, and the OpenBSD device tree should follow that. If you
> look at the device trees for the imx6 and exynos boards for example,
> you see that there is a "soc" node. The ehci and ahci are below that
> "soc" node in the device tree. You can differentiate between
> different SoCs based on the properties of this "soc" node, and attach
> different drivers based on that. Then you can have specific ahci and
> ehci attachments for each SoC.
>
> So you'd have:
>
> imx* at mainbus?
> ehci* at imx?
>
> and in your files.xxx you'd have something like:
>
> attach ehci at imx with ehci_imx
> file arch/armv7/imx/ehci_imx.c ehci_imx
>
>
> Cheers,
>
> Mark
>
I don't think that's a good idea. Let's take the FreeScale (NXP)
LS1021A SoC and look at the device tree. There's a USB controller:
usb3@3100000 {
compatible = "snps,dwc3";
[...]
};
This is the Synopsis DesignWare Controller. It's not NXP-specific.
The same controller is used in other SoCs, for instance:
exynos5420.dtsi: compatible = "snps,dwc3";
exynos5420.dtsi: compatible = "snps,dwc3";
omap5.dtsi: compatible = "snps,dwc3";
This would mean that I would need one SoC bus per supported SoC
and one xhci driver per SoC. In practice, there's no difference
between the OMAP and the LS1 controller.
Implementing a new board would mean that I also need to write code
for a new SoC bus and it wouldn't just work out-of-the-box?
So what I thought would be better would be something like:
mainbus0 at root
dwcxhci0 at mainbus0
xhci0 at mainbus0
Then you don't need those SoC busses and new platforms should work
nearly out-of-the-box.
Patrick
