From: 김승우 <sw0312.kim@samsung.com> To: Sean Paul <seanpaul@chromium.org> Cc: Stephen Warren <swarren@wwwdotorg.org>, Tomasz Stanislawski <t.stanislaws@samsung.com>, "kgene.kim" <kgene.kim@samsung.com>, devicetree-discuss@lists.ozlabs.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, dri-devel@lists.freedesktop.org, Tomasz Figa <tomasz.figa@gmail.com>, linux-samsung-soc@vger.kernel.org, Sylwester Nawrocki <sylvester.nawrocki@gmail.com>, Olof Johansson <olofj@chromium.org>, linux-arm-kernel@lists.infradead.org, RAHUL SHARMA <rahul.sharma@samsung.com>, sw0312.kim@samsung.com Subject: Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree Date: Wed, 06 Feb 2013 11:56:59 +0900 [thread overview] Message-ID: <5111C67B.3060909@samsung.com> (raw) In-Reply-To: <CAOw6vbKhsWp7VnqgvECd-P4e5okX6dwKn3P8+phfpG29rA+h7g@mail.gmail.com> On 2013년 02월 06일 09:56, Sean Paul wrote: > On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 02/05/2013 05:37 PM, Sean Paul wrote: >>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>> n 02/05/2013 04:42 PM, Sean Paul wrote: >>>>> Use the compatible string in the device tree to determine which >>>>> registers/functions to use in the HDMI driver. Also changes the >>>>> references from v13 to 4210 and v14 to 4212 to reflect the IP >>>>> block version instead of the HDMI version. >>>> >>>>> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt >>>> >>>> Binding looks sane to me. >>>> >>>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c >>>> >>>>> #ifdef CONFIG_OF >>>>> static struct of_device_id hdmi_match_types[] = { >>>>> { >>>>> - .compatible = "samsung,exynos5-hdmi", >>>>> - .data = (void *)HDMI_TYPE14, >>>>> + .compatible = "samsung,exynos4-hdmi", >>>>> }, { >>>>> /* end node */ >>>>> } >>>> >>>> Why not fill in all the "base" compatible values there (I think you need >>>> this anyway so that DTs don't all have to be compatible with >>>> samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS* >>>> values, then ... >>>> >>> >>> At the moment, all DTs have to be compatible with exynos4-hdmi since >>> it provides the base for the current driver. The driver uses 4210 and >>> 4212 to differentiate between different register addresses and >>> features, but most things are just exynos4-hdmi compatible. >> >> The DT nodes should include only the compatible values that the HW is >> actually compatible with. If the HW isn't compatible with exynos4-hdmi, >> that value shouldn't be in the compatible property, but instead whatever >> the "base" value that the HW really is compatible with. The driver can >> support multiple "base" compatible values from this table. >> > > All devices that use this driver are compatible, at some level, with > exynos4-hdmi, so I think its usage is correct here. > >>>>> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev) >>>> >>>>> + >>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4210-hdmi")) >>>>> + hdata->version |= HDMI_VER_EXYNOS4210; >>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4212-hdmi")) >>>>> + hdata->version |= HDMI_VER_EXYNOS4212; >>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos5250-hdmi")) >>>>> + hdata->version |= HDMI_VER_EXYNOS5250; >>>> >>>> Instead of that, do roughly: >>>> >>>> match = of_match_device(hdmi_match_types, &pdev->dev); >>>> if (match) >>>> hdata->version |= (int)match->data; >>>> >>>> That way, it's all table-based. Any future additions to >>>> hdmi_match_types[] won't require another if statement to be added to >>>> probe(). >>> >>> I don't think it's that easy. of_match_device returns the first match >>> from the device table, so I'd still need to iterate through the >>> matches. I could still break this out into a table, but I don't think >>> of_match_device is the right way to probe it. >> >> You shouldn't have to iterate over multiple matches. of_match_device() >> is supposed to return the match for the first entry in the compatible >> property, then if there was no match, move on to looking at the next >> entry in the compatible property, etc. In practice, I think it's still >> not implemented quite correctly for this, but you can make it work by >> putting the newest compatible value first in the match table. > > I think the only way that works is if you hardcode the compatible > versions in the driver, like this: > > static struct of_device_id hdmi_match_types[] = { > { > .compatible = "samsung,exynos5250-hdmi", > .data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212); > }, { > .compatible = "samsung,exynos4212-hdmi", > .data = (void *)HDMI_VER_EXYNOS4212; > }, { > .compatible = "samsung,exynos4210-hdmi", > .data = (void *)HDMI_VER_EXYNOS4210; > }, { > /* end node */ > } > }; Actually, I can't understand why there is HDMI_VER_EXYNOS5250 because it is not used anywhere in your patch. I'm not sure I missed something from your v2 patch thread, but to me, just hdmi version or hdmi ip version can be used as data field of struct of_device_id as like your v2 patch set. and then of_match_device() can be used without | in data field. If I have missed some point from v2 thread, please let me know. Best Regards, - Seung-Woo Kim > > In that case, it eliminates the benefit of using device tree to > determine the compatible bits. I hope I'm just being thick and missing > something. > > Sean > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Seung-Woo Kim Samsung Software R&D Center --
WARNING: multiple messages have this Message-ID
From: sw0312.kim@samsung.com (김승우) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree Date: Wed, 06 Feb 2013 11:56:59 +0900 [thread overview] Message-ID: <5111C67B.3060909@samsung.com> (raw) In-Reply-To: <CAOw6vbKhsWp7VnqgvECd-P4e5okX6dwKn3P8+phfpG29rA+h7g@mail.gmail.com> On 2013? 02? 06? 09:56, Sean Paul wrote: > On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 02/05/2013 05:37 PM, Sean Paul wrote: >>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>> n 02/05/2013 04:42 PM, Sean Paul wrote: >>>>> Use the compatible string in the device tree to determine which >>>>> registers/functions to use in the HDMI driver. Also changes the >>>>> references from v13 to 4210 and v14 to 4212 to reflect the IP >>>>> block version instead of the HDMI version. >>>> >>>>> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt >>>> >>>> Binding looks sane to me. >>>> >>>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c >>>> >>>>> #ifdef CONFIG_OF >>>>> static struct of_device_id hdmi_match_types[] = { >>>>> { >>>>> - .compatible = "samsung,exynos5-hdmi", >>>>> - .data = (void *)HDMI_TYPE14, >>>>> + .compatible = "samsung,exynos4-hdmi", >>>>> }, { >>>>> /* end node */ >>>>> } >>>> >>>> Why not fill in all the "base" compatible values there (I think you need >>>> this anyway so that DTs don't all have to be compatible with >>>> samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS* >>>> values, then ... >>>> >>> >>> At the moment, all DTs have to be compatible with exynos4-hdmi since >>> it provides the base for the current driver. The driver uses 4210 and >>> 4212 to differentiate between different register addresses and >>> features, but most things are just exynos4-hdmi compatible. >> >> The DT nodes should include only the compatible values that the HW is >> actually compatible with. If the HW isn't compatible with exynos4-hdmi, >> that value shouldn't be in the compatible property, but instead whatever >> the "base" value that the HW really is compatible with. The driver can >> support multiple "base" compatible values from this table. >> > > All devices that use this driver are compatible, at some level, with > exynos4-hdmi, so I think its usage is correct here. > >>>>> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev) >>>> >>>>> + >>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4210-hdmi")) >>>>> + hdata->version |= HDMI_VER_EXYNOS4210; >>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4212-hdmi")) >>>>> + hdata->version |= HDMI_VER_EXYNOS4212; >>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos5250-hdmi")) >>>>> + hdata->version |= HDMI_VER_EXYNOS5250; >>>> >>>> Instead of that, do roughly: >>>> >>>> match = of_match_device(hdmi_match_types, &pdev->dev); >>>> if (match) >>>> hdata->version |= (int)match->data; >>>> >>>> That way, it's all table-based. Any future additions to >>>> hdmi_match_types[] won't require another if statement to be added to >>>> probe(). >>> >>> I don't think it's that easy. of_match_device returns the first match >>> from the device table, so I'd still need to iterate through the >>> matches. I could still break this out into a table, but I don't think >>> of_match_device is the right way to probe it. >> >> You shouldn't have to iterate over multiple matches. of_match_device() >> is supposed to return the match for the first entry in the compatible >> property, then if there was no match, move on to looking at the next >> entry in the compatible property, etc. In practice, I think it's still >> not implemented quite correctly for this, but you can make it work by >> putting the newest compatible value first in the match table. > > I think the only way that works is if you hardcode the compatible > versions in the driver, like this: > > static struct of_device_id hdmi_match_types[] = { > { > .compatible = "samsung,exynos5250-hdmi", > .data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212); > }, { > .compatible = "samsung,exynos4212-hdmi", > .data = (void *)HDMI_VER_EXYNOS4212; > }, { > .compatible = "samsung,exynos4210-hdmi", > .data = (void *)HDMI_VER_EXYNOS4210; > }, { > /* end node */ > } > }; Actually, I can't understand why there is HDMI_VER_EXYNOS5250 because it is not used anywhere in your patch. I'm not sure I missed something from your v2 patch thread, but to me, just hdmi version or hdmi ip version can be used as data field of struct of_device_id as like your v2 patch set. and then of_match_device() can be used without | in data field. If I have missed some point from v2 thread, please let me know. Best Regards, - Seung-Woo Kim > > In that case, it eliminates the benefit of using device tree to > determine the compatible bits. I hope I'm just being thick and missing > something. > > Sean > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Seung-Woo Kim Samsung Software R&D Center --
next prev parent reply other threads:[~2013-02-06 2:56 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-05 23:42 [PATCH v3 0/2] Get the HDMI IP block " Sean Paul 2013-02-05 23:42 ` Sean Paul 2013-02-05 23:42 ` [PATCH v3 1/3] drm/exynos: Get HDMI " Sean Paul 2013-02-05 23:42 ` Sean Paul 2013-02-06 0:22 ` Stephen Warren 2013-02-06 0:22 ` Stephen Warren 2013-02-06 0:37 ` Sean Paul 2013-02-06 0:37 ` Sean Paul 2013-02-06 0:37 ` Sean Paul 2013-02-06 0:42 ` Stephen Warren 2013-02-06 0:42 ` Stephen Warren 2013-02-06 0:47 ` Kyungmin Park 2013-02-06 0:47 ` Kyungmin Park 2013-02-06 0:56 ` Sean Paul 2013-02-06 0:56 ` Sean Paul 2013-02-06 1:48 ` Joonyoung Shim 2013-02-06 1:48 ` Joonyoung Shim 2013-02-06 2:49 ` Stephen Warren 2013-02-06 2:49 ` Stephen Warren 2013-02-06 2:56 ` 김승우 [this message] 2013-02-06 2:56 ` 김승우 2013-02-06 19:01 ` Olof Johansson 2013-02-06 19:01 ` Olof Johansson 2013-02-05 23:42 ` [PATCH v3 2/3] ARM: Change exynos5-hdmi references to exynos4-hdmi Sean Paul 2013-02-05 23:42 ` Sean Paul
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=5111C67B.3060909@samsung.com \ --to=sw0312.kim@samsung.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=kgene.kim@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=olofj@chromium.org \ --cc=rahul.sharma@samsung.com \ --cc=seanpaul@chromium.org \ --cc=swarren@wwwdotorg.org \ --cc=sylvester.nawrocki@gmail.com \ --cc=t.stanislaws@samsung.com \ --cc=tomasz.figa@gmail.com \ --subject='Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree' \ /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
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.