From: Jon Hunter <jon-hunter@ti.com>
To: "Cousson, Benoit" <b-cousson@ti.com>
Cc: Xiao Jiang <jgq516@gmail.com>,
linux@arm.linux.org.uk, rob.herring@calxeda.com,
grant.likely@secretlab.ca, rnayak@ti.com, tony@atomide.com,
wim@iguana.be, devicetree-discuss@lists.ozlabs.org,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-watchdog@vger.kernel.org
Subject: Re: [PATCH 3/3] watchdog: omap_wdt: add device tree support
Date: Wed, 30 May 2012 11:12:47 -0500 [thread overview]
Message-ID: <4FC646FF.1000209@ti.com> (raw)
In-Reply-To: <4FC63D03.8080501@ti.com>
Hi Benoit,
On 05/30/2012 10:30 AM, Cousson, Benoit wrote:
> Hi Jon,
>
> On 5/30/2012 5:03 PM, Jon Hunter wrote:
>> Hi Benoit,
>>
>> On 05/30/2012 02:54 AM, Cousson, Benoit wrote:
>>> On 5/30/2012 5:18 AM, Xiao Jiang wrote:
>>>> Jon Hunter wrote:
>>>>> On 05/25/2012 05:42 AM, jgq516@gmail.com wrote:
>>>>>> From: Xiao Jiang<jgq516@gmail.com>
>>>>>>
>>>>>> Add device table for omap_wdt to support dt.
>>>>>>
>>>>>> Signed-off-by: Xiao Jiang<jgq516@gmail.com>
>>>>>> ---
>>>>>> drivers/watchdog/omap_wdt.c | 8 ++++++++
>>>>>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/watchdog/omap_wdt.c
>>>>>> b/drivers/watchdog/omap_wdt.c
>>>>>> index 8285d65..d98c615 100644
>>>>>> --- a/drivers/watchdog/omap_wdt.c
>>>>>> +++ b/drivers/watchdog/omap_wdt.c
>>>>>> @@ -430,6 +430,13 @@ static int omap_wdt_resume(struct
>>>>>> platform_device *pdev)
>>>>>> #define omap_wdt_resume NULL
>>>>>> #endif
>>>>>>
>>>>>> +static const struct of_device_id omap_wdt_of_match[] = {
>>>>>> + { .compatible = "ti,omap3-wdt", },
>>>>>> + { .compatible = "ti,omap4-wdt", },
>>>
>>> If there is no difference between the OMAP3 and the OMAP4 WDT IP, just
>>> add one entry "ti,omap3-wdt". And then in the OMAP4 DTS you will just
>>> put : compatible = "ti,omap3-wdt"; or compatible = "ti,omap4-wdt",
>>> "ti,omap3-wdt";
>>
>> Hmmm ... comparing the omap3 and omap4 wdt registers there are some
>> differences. omap4 seems to have more registers than omap3. May be we
>> are not using these right now, but from a register perspective the wdt
>> in omap2, omap3 and omap4 appear to be slightly different. The revision
>> ID register on omap3 and omap4 have different values too.
>>
>> I guess from a driver perspective there is no difference, but it seemed
>> to me that the IP is not completely the same.
>
> Well, in that case, and assuming that there is no proper HW_REVISION
> information to detect the IP difference, the proper compatible entries
> will indeed have to be used.
So looking at a 4460 and 3430, the WIDR register (IP revision) can be
used to distinguish between IP revisions. So it appears that we do have
proper HW REV info.
So may be I am not completely up to speed of the intent of the
compatible field. In other words, should this be used to indicate if the
IP is same/compatible or the driver is compatible or both. Technically
right now we could just have "ti-omap2-wdt" for all omap2+ devices as
the driver is compatible for all devices. However, technically, the IP
is not completely the same but it is compatible :-)
>>> I'm still a little bit confused about the real need for the
>>> "ti,omap4-wdt: entry, but it seems to be the way to do it in PPC.
>>>
>>>>>> + {},
>>>>>> +};
>>>>>> +MODULE_DEVICE_TABLE(of, omap_wdt_of_match);
>>>>>> +
>>>>>> static struct platform_driver omap_wdt_driver = {
>>>>>> .probe = omap_wdt_probe,
>>>>>> .remove = __devexit_p(omap_wdt_remove),
>>>>>> @@ -439,6 +446,7 @@ static struct platform_driver omap_wdt_driver = {
>>>>>> .driver = {
>>>>>> .owner = THIS_MODULE,
>>>>>> .name = "omap_wdt",
>>>>>> + .of_match_table = omap_wdt_of_match,
>>>>>> },
>>>>>> };
>>>>>>
>>>>>
>>>>> I think we need to add some code to the probe function that calls
>>>>> of_match_device() and ensures we find a match. For example ...
>>>>>
>>>>> if (of_have_populated_dt())
>>>>> if (!of_match_device(omap_wdt_of_match,&pdev->dev))
>>>>> return -EINVAL;
>>>>>
>>>> Will add it in v2, thanks for suggestion.
>>>
>>> No, in fact this is not needed. We need that mainly when several
>>> instances can match the same driver and thus we select the proper one
>>> using the of_match_device. Otherwise, just check is the device_node is
>>> there.
>>>
>>> In that case, the driver does not even care about any DT node so there
>>> is no need to add extra code for that. Keep it simple.
>>
>> Ok. So are you saying get rid of the match table altogether? In other
>> words, drop this patch?
>
> No, the match table is used by the LDM to find the proper driver to be
> bound to a device. So we do need it. But we do not have to use the
> of_match_device if we do not want to get the entry in the device table.
Ok, thanks.
>> I agree that it does not really do anything today, but I did not know if
>> in the future you were planning to pass things like, register addresses,
>> via DT.
>
> Well, yes we will have to, otherwise people will keep complaining that
> our DTS sucks and are not compliant with the DTS standards :-)
Ok.
Jon
next prev parent reply other threads:[~2012-05-30 16:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 10:42 [PATCH 0/3] omap3/omap4: add device tree support for wdt jgq516
2012-05-25 10:42 ` [PATCH 1/3] arm/dts: add wdt node for omap3 and omap4 jgq516
2012-05-29 17:52 ` Jon Hunter
2012-05-30 3:19 ` Xiao Jiang
2012-05-30 14:42 ` Jon Hunter
2012-05-31 5:51 ` Xiao Jiang
2012-05-31 14:55 ` Jon Hunter
2012-05-31 20:59 ` Cousson, Benoit
2012-05-25 10:42 ` [PATCH 2/3] OMAP: avoid build wdt platform device if with dt support jgq516
2012-05-29 17:53 ` Jon Hunter
2012-05-25 10:42 ` [PATCH 3/3] watchdog: omap_wdt: add device tree support jgq516
2012-05-29 18:06 ` Jon Hunter
2012-05-30 3:18 ` Xiao Jiang
2012-05-30 7:54 ` Cousson, Benoit
2012-05-30 10:14 ` Xiao Jiang
2012-05-30 10:31 ` Xiao Jiang
2012-05-30 15:03 ` Jon Hunter
2012-05-30 15:30 ` Cousson, Benoit
2012-05-30 16:12 ` Jon Hunter [this message]
2012-05-29 17:47 ` [PATCH 0/3] omap3/omap4: add device tree support for wdt Jon Hunter
2012-05-30 10:14 ` Xiao Jiang
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=4FC646FF.1000209@ti.com \
--to=jon-hunter@ti.com \
--cc=b-cousson@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=jgq516@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=rnayak@ti.com \
--cc=rob.herring@calxeda.com \
--cc=tony@atomide.com \
--cc=wim@iguana.be \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).