On Fri, Dec 04, 2015 at 05:41:45PM +0100, Lucas Stach wrote: > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring: > > On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote: > > > +gpu-subsystem { > > > + compatible = "fsl,imx-gpu-subsystem"; > > > + cores = <&gpu_2d>, <&gpu_3d>; > > > +}; > > > > Yeah, I'm not really a fan of doing this simply because DRM wants 1 > > driver. > > > I'm aware of that, but I don't see much value in kicking this discussion > around for every DRM driver submission. This is the binding that has > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least > allows us to standardize on _something_. Also ALSA does a similar thing > to bind codecs and CPU interfaces together.
Absolutely, this is the interface and method that was discussed and settled upon, and for DT folk to now start saying that they're not fans of it is _far_ too late. If they had concerns, they should have been discussed during the submission of the first users of it, not after the 4th or 5th user. Sure, they may be having reservations about it, but then, I think, it's up to them to come up with a better solution to this, and discuss it over with the DRM people, remembering that the DRM people are very adamant that they're not budging on the "not hotplugging bits" issue, or if they do, it means _radically_ changing the DRM user API for everything. > > Also, it probably should have an SOC specific property to deal with SOC > > specific configuration or integration. > > Same as above really. Parts of the identification registers are > different for each SoC integration, even if it's the same IP core, > so we can just derive any needed driver behavior differences from > that. I agree. There are some bugs in various cores (like the GC320) but it's not clear whether that's a SoC specific issue or whether it's a GPU core specific issue: all we know is that GC320 revision X suffers from a certain bug, which we need to work around in userspace - and as we pass all the GPU identifying information to userspace, adding such stuff into DT, and then having to find some way to pass it through to userspace would just add a whole new level of complexity that isn't required. It'd be a case of "okay, we know iMX6 has a GC320 with revision X, so we better set DT flag Y to indicate that it has this bug" when we already know in userspace that it's a GC320 revision X and userspace needs to generate the command stream differently based on that. So, it seems completely pointless to encode this information in DT. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.