> -----Original Message----- > From: Sylwester Nawrocki [mailto:sylvester.nawrocki@xxxxxxxxx] > Sent: Thursday, January 31, 2013 5:51 AM > To: Inki Dae > Cc: Sachin Kamat; linux-media@xxxxxxxxxxxxxxx; dri- > devel@xxxxxxxxxxxxxxxxxxxxx; devicetree-discuss@xxxxxxxxxxxxxxxx; > patches@xxxxxxxxxx; s.nawrocki@xxxxxxxxxxx > Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery > support for G2D > > On 01/30/2013 09:50 AM, Inki Dae wrote: > >> +static const struct of_device_id exynos_g2d_match[] = { > >> + { .compatible = "samsung,g2d-v41" }, > > > > not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d > > driver shoud support for all Exynos SoCs. How about using > > "samsung,exynos5-g2d" instead and adding a new property 'version' to > > identify ip version more surely? With this, we could know which SoC > > and its g2d ip version. The version property could have '0x14' or > > others. And please add descriptions to dt document. > > Err no. Are you suggesting using "samsung,exynos5-g2d" compatible string > for Exynos4 specific IPs ? This would not be correct, and you still can I assumed the version 'v41' is the ip for Exynos5 SoC. So if this version means Exynos4 SoC then it should be "samsung,exynos4-g2d". > match the driver with multiple different revisions of the IP and associate > any required driver's private data with each corresponding compatible > property. > Right, and for why I prefer to use version property instead of embedded version string, you can refer to the my comment I replied already to the "drm/exynos: Get HDMI version from device tree" email thread. > Perhaps it would make more sense to include the SoCs name in the > compatible > string, e.g. "samsung,exynos-g2d-v41", but appending revision of the IP > seems acceptable to me. The revisions appear to be well documented and > it's > more or less clear which one corresponds to which SoC. > > -- > > Thanks, > Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html