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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
