On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt <eric@xxxxxxxxxx> wrote: > Stephen Warren <swarren@xxxxxxxxxxxxx> writes: > >> On 08/12/2015 06:56 PM, Eric Anholt wrote: >>> Signed-off-by: Eric Anholt <eric@xxxxxxxxxx> >> >> This one definitely needs a patch description, since someone might not >> know what a VC4 is, and "git log" won't show the text from the binding >> doc itself. I'd suggest adding the initial paragraph of the binding doc >> as the patch description, or more. >> >>> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt > >>> +- hvss: List of references to HVS video scalers >>> +- encoders: List of references to output encoders (HDMI, SDTV) >> >> Would it make sense to make all those nodes child node of the vc4 >> object. That way, there's no need to have these lists of objects; they >> can be automatically built up as the DT is enumerated. I know that e.g. >> the NVIDIA Tegra host1x binding works this way, and I think it may have >> been inspired by other similar cases. > > I've looked at tegra, and the component system used by msm appears to be > nicer than it. To follow tegra's model, it looks like I need to build > this extra bus thing corresponding to host1x that is effectively the > drivers/base/component.c code, so that I can get at vc4's structure from > the component drivers. > >> Of course, this is only appropriate if the HW modules really are >> logically children of the VC4 HW module. Perhaps they aren't. If they >> aren't though, I wonder what this "vc4" module actually represents in HW? > > It's the subsystem, same as we use a subsystem node for msm, sti, > rockchip, imx, and exynos. This appears to be the common model of how > the collection of graphics-related components is represented in the DT. I think most of these bindings are wrong. They are grouped together because that is what DRM wants not because that reflects the h/w. So convince me this is one block, not that it is what other people do. Rob _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
