From: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Sachin Kamat <sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Kukjin Kim <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Sylwester Nawrocki
<sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Date: Fri, 01 Feb 2013 11:54:00 +0100 [thread overview]
Message-ID: <510B9EC8.6020102@samsung.com> (raw)
In-Reply-To: <CAK9yfHxqqumg-oqH_Ku8Zkf8biWVknF91Su0VkWJJXjvWQ3Jhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 02/01/2013 09:33 AM, Sachin Kamat wrote:
> On 1 February 2013 06:57, Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>
>> For example,
>> If compatible = "samsung,g2d-3.0" is added to exynos4210.dtsi, it'd be
>> reasonable. But what if that compatible string is added to exynos4.dtsi?.
>> This case isn't considered for exynos4412 SoC with v4.1.
>
> In case of Exynos4 series the base address of G2D ip is different
> across series. Hence we cannot define it in exynos4.dtsi and need to
> define the nodes in exynos4xxx.dtsi or specific board files. Thus we
> can use the version appended compatible string.
>
> However even the second option suggested by Sylwester is OK with me or
> to be even more specific we could go for both SoC as well as version
> option something like this.
>
> compatible = "samsung,exynos3110-g2d-3.0" /* for Exynos3110, Exynos4210 */
> compatible = "samsung,exynos4212-g2d-4.1" /* for Exynos4212, Exynos4412 */
>
> In any case please let me know the final preferred one so that I can
> update the code send the revised patches.
The version with SoC name embedded in it seems most reliable and correct
to me.
compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, S5PV210),
Exynos4210 */
compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, Exynos4412 */
FIMG stands for Fully Interactive Mobile Graphics, and other multimedia
IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller),
FIMC (Camera), etc.
This is just my opinion though, and it seems this is a most common scheme
from greping the device tree bindings documentation.
As Stephen pointed out, and I also did in some other mail thread in the
past, not only an IP revision might be required, but also its integration
details, specific to an SoC type are important. This actually happens
to be the case with FIMC, where same version of one instance of the IP
has more data interfaces routed to other SoC subsystems on one SoC type
than on other one.
I think it won't be possible to use a scheme like "samsung-exynos-g2d-3.0"
for all IPs. And I would much more like to see a uniform naming convention
used, rather than living with a chaotic set of compatible properties, that
has a potential to become even more chaotic in the future.
--
Thanks,
Sylwester
WARNING: multiple messages have this Message-ID (diff)
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Inki Dae <inki.dae@samsung.com>,
Kukjin Kim <kgene.kim@samsung.com>,
Sylwester Nawrocki <sylvester.nawrocki@gmail.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
devicetree-discuss@lists.ozlabs.org, patches@linaro.org
Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Date: Fri, 01 Feb 2013 11:54:00 +0100 [thread overview]
Message-ID: <510B9EC8.6020102@samsung.com> (raw)
In-Reply-To: <CAK9yfHxqqumg-oqH_Ku8Zkf8biWVknF91Su0VkWJJXjvWQ3Jhw@mail.gmail.com>
On 02/01/2013 09:33 AM, Sachin Kamat wrote:
> On 1 February 2013 06:57, Inki Dae <inki.dae@samsung.com> wrote:
>>
>> For example,
>> If compatible = "samsung,g2d-3.0" is added to exynos4210.dtsi, it'd be
>> reasonable. But what if that compatible string is added to exynos4.dtsi?.
>> This case isn't considered for exynos4412 SoC with v4.1.
>
> In case of Exynos4 series the base address of G2D ip is different
> across series. Hence we cannot define it in exynos4.dtsi and need to
> define the nodes in exynos4xxx.dtsi or specific board files. Thus we
> can use the version appended compatible string.
>
> However even the second option suggested by Sylwester is OK with me or
> to be even more specific we could go for both SoC as well as version
> option something like this.
>
> compatible = "samsung,exynos3110-g2d-3.0" /* for Exynos3110, Exynos4210 */
> compatible = "samsung,exynos4212-g2d-4.1" /* for Exynos4212, Exynos4412 */
>
> In any case please let me know the final preferred one so that I can
> update the code send the revised patches.
The version with SoC name embedded in it seems most reliable and correct
to me.
compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, S5PV210),
Exynos4210 */
compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, Exynos4412 */
FIMG stands for Fully Interactive Mobile Graphics, and other multimedia
IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller),
FIMC (Camera), etc.
This is just my opinion though, and it seems this is a most common scheme
from greping the device tree bindings documentation.
As Stephen pointed out, and I also did in some other mail thread in the
past, not only an IP revision might be required, but also its integration
details, specific to an SoC type are important. This actually happens
to be the case with FIMC, where same version of one instance of the IP
has more data interfaces routed to other SoC subsystems on one SoC type
than on other one.
I think it won't be possible to use a scheme like "samsung-exynos-g2d-3.0"
for all IPs. And I would much more like to see a uniform naming convention
used, rather than living with a chaotic set of compatible properties, that
has a potential to become even more chaotic in the future.
--
Thanks,
Sylwester
next prev parent reply other threads:[~2013-02-01 10:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-25 9:55 [PATCH 1/2] [media] s5p-g2d: Add DT based discovery support Sachin Kamat
2013-01-25 9:55 ` [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D Sachin Kamat
2013-01-30 8:50 ` Inki Dae
2013-01-30 20:51 ` Sylwester Nawrocki
2013-01-31 1:30 ` Inki Dae
2013-01-31 23:47 ` Sylwester Nawrocki
2013-02-01 0:15 ` Kukjin Kim
2013-02-01 1:27 ` Inki Dae
2013-02-01 2:26 ` Stephen Warren
2013-02-01 8:33 ` Sachin Kamat
[not found] ` <CAK9yfHxqqumg-oqH_Ku8Zkf8biWVknF91Su0VkWJJXjvWQ3Jhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-01 10:54 ` Sylwester Nawrocki [this message]
2013-02-01 10:54 ` Sylwester Nawrocki
2013-02-01 11:12 ` Sachin Kamat
2013-02-01 11:32 ` Inki Dae
2013-02-01 11:40 ` Sachin Kamat
2013-02-01 11:52 ` Inki Dae
2013-02-01 12:58 ` Inki Dae
[not found] ` <E382E0B5-2695-4293-B264-FB4C54FE4F9D-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-02-04 12:04 ` Sachin Kamat
2013-02-04 12:04 ` Sachin Kamat
2013-02-05 3:03 ` Inki Dae
2013-02-05 4:21 ` Kyungmin Park
2013-02-05 7:56 ` 김승우
2013-02-05 8:32 ` Joonyoung Shim
2013-02-05 9:33 ` Sylwester Nawrocki
2013-02-05 9:33 ` Sylwester Nawrocki
2013-02-06 4:14 ` Sachin Kamat
2013-02-01 17:35 ` Kukjin Kim
2013-02-01 18:06 ` Kukjin Kim
2013-01-30 21:38 ` [PATCH 1/2] [media] s5p-g2d: Add DT based discovery support Sylwester Nawrocki
2013-01-31 6:29 ` Sachin Kamat
-- strict thread matches above, loose matches on Subject: below --
2013-02-06 5:29 [PATCH v2 " Sachin Kamat
2013-02-06 5:29 ` [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D Sachin Kamat
2013-02-12 13:17 ` Inki Dae
[not found] ` <CAAQKjZNmUVZnDcy3fbWkairnneOK7dooJT2gn=9++tzS=uhhzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-12 17:22 ` [PATCH " Sachin Kamat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=510B9EC8.6020102@samsung.com \
--to=s.nawrocki-sze3o3uu22jbdgjk7y7tuq@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.