On Fri, Nov 18, 2016 at 7:34 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote:
> Am Freitag, den 18.11.2016, 12:13 +0000 schrieb Russell King - ARM
> Linux:
>> On Thu, Nov 17, 2016 at 08:53:38PM -0600, Nishanth Menon wrote:
>> > >diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >index a6799b0..ce51270 100644
>> > >--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >@@ -653,6 +653,7 @@ static int etnaviv_pdev_remove(struct platform_device *pdev)
>> > > static const struct of_device_id dt_match[] = {
>> > > { .compatible = "fsl,imx-gpu-subsystem" },
>> > > { .compatible = "marvell,dove-gpu-subsystem" },
>> > >+ { .compatible = "ti,gc320-gpu-subsystem" },
>>
>> We need to get away from this ever-increasing set of compatible
>> strings here, as this is not long-term maintainable.
>>
>> What we should have is a common compatible which describes that
>> the node is compatible with this driver, and then use SoC specific
>> compatible strings later if we need to (eg, because of some GPU
>> subsystem SoC specifics.)
>>
>> So, I'd suggest that we update the documentation and add:
>>
>> "vivante,gc-gpu-subsystem"
>>
>> as a common compatible now, and if necessary move on to more specific
>> compatibles if we need to later.
>>
>> Also, I'd strongly suggest that no compatibles should contain the ID
>> number of the GPU core for exactly the same reason - Vivante GPU cores
>> vary according to features, and we don't want to end up with a long
>> list of specific compatibles (eg)
>> "ti,gc2000-and-gc320-and-gc355-gpu-subsystem" because TI
>> decides to integrate a 3d, 2d and VG core.
>>
> All of the above sounds sensible and I would prefer if the patches are
> reworked to take those things into account.
Thanks for reviewing guys, the "vivante,gc-gpu-subsystem" will work
perfectly fine for me, as the etnaviv driver does a great job at auto
detecting the hardware..
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
