devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: grant.likely@secretlab.ca, Samuel Ortiz <sameo@linux.intel.com>,
	rabin.vincent@stericsson.com, shiraz.hashim@st.com,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, spear-devel@list.st.com,
	linus.walleij@linaro.org,
	Vipul Kumar Samar <vipulkumar.samar@st.com>
Subject: Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver
Date: Wed, 5 Dec 2012 13:19:04 +0000	[thread overview]
Message-ID: <20121205131904.GJ2718@gmail.com> (raw)
In-Reply-To: <CAKohpom-9fFwvCQXdJNXELZC1rfDT0-N+XoYQdTOG2Mo=SyiYw@mail.gmail.com>

> Ping!!!

Documentation/development-process/2.Process:

- Avoid top-posting (the practice of putting your answer above the quoted
  text you are responding to).  It makes your response harder to read and
  makes a poor impression.

:)

> On 1 December 2012 00:33, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 30 November 2012 21:15, Lee Jones <lee.jones@linaro.org> wrote:
> >> But ... I don't see how the changes in the -i2c and -spi files
> >> are of benefit either. When I boot without the ID table I still
> >> get "stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212".
> >>
> >> What is it that actually uses the IDs?
> >>
> >> Perhaps Viresh can shine some light on the matter?
> >
> > As you can see, i wasn't the author of this patch and when you asked
> > this question, i didn't had an answer to it. I went through code and
> > formed some theory/story :) .
> >
> > @Grant: i need your help to check if my theory is correct or not. Question
> > is about adding below code in any i2c client driver:
> >
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id stmpe_dt_ids[] = {
> > +       { .compatible = "st,stmpe610", .data = &stmpe_i2c_id[0], },
> > +       { .compatible = "st,stmpe801", .data = &stmpe_i2c_id[1], },
> > +       { .compatible = "st,stmpe811", .data = &stmpe_i2c_id[2], },
> > +       { .compatible = "st,stmpe1601", .data = &stmpe_i2c_id[3], },
> > +       { .compatible = "st,stmpe2401", .data = &stmpe_i2c_id[4], },
> > +       { .compatible = "st,stmpe2403", .data = &stmpe_i2c_id[5], },
> > +       { }
> > +};
> > +MODULE_DEVICE_TABLE(of, stmpe_dt_ids);
> > +#endif
> > +
> >  static struct i2c_driver stmpe_i2c_driver = {
> >         .driver = {
> >                 .name = "stmpe-i2c",
> > @@ -88,6 +102,7 @@ static struct i2c_driver stmpe_i2c_driver = {
> >  #ifdef CONFIG_PM
> >                 .pm = &stmpe_dev_pm_ops,
> >  #endif
> > +               .of_match_table = of_match_ptr(stmpe_dt_ids),
> >
> > So, what is the use of this table when we already have i2c_driver.id_table
> > populated.
> >
> > This is my theory:
> > ---------------------
> > Adapter drivers supporting DT will call:
> > of_i2c_register_devices()
> > {
> >         for_each_child_of_node(adap->dev.of_node, node) {
> >                 if (of_modalias_node(node, info.type, sizeof(info.type)) < 0)
> >                      error condition
> >
> >                 ...
> >                 result = i2c_new_device(adap, &info);
> >
> >           ...
> > }
> >
> > of_modalias_node(): expects compatible in child node, i.e. stmpe node in our
> > case. If it is not there, then that node is skipped. then it copies
> > string after ','
> > to info.type. So, for us only "stmpe810" out of "st,stmpe810" is copied.
> >
> > Now this name, i.e. "stmpe810" is copied as client.name in i2c_new_device()
> > and device_register() is called, which will eventually call:
> >
> > i2c_device_match()
> > {
> >         /* Attempt an OF style match */
> >         if (of_driver_match_device(dev, drv))
> >                 return 1;
> >
> >         driver = to_i2c_driver(drv);
> >         /* match on an id table if there is one */
> >         if (driver->id_table)
> >                 return i2c_match_id(driver->id_table, client) != NULL;
> > }
> >
> > This first tries to match the table my patch added, _BUT_ the string will
> > never match as we had "st,stmpe810" in table and "stmpe810" in dev.
> >
> > So, we fall back to i2c_match_id(), which will match it against
> > i2c_driver.id_table present in driver, which has entry for "stmpe810" and
> > so strings matched.
> >
> > @Lee: This is what happened in your case. :)
> >
> > So, whether its DT or non DT, true is returned from here if something
> > matched.
> >
> > Later on, this will be called:
> >
> > static int i2c_device_probe(struct device *dev)
> > {
> >         .....
> >         status = driver->probe(client, i2c_match_id(driver->id_table, client));
> >         ....
> > }
> >
> > Which will again match the legacy table to find correct struct i2c_device_id *id
> > to pass to probe().
> >
> > So, the final question: WTF is of_match_table for?
> >
> > Then i thought maybe it is used when  we don't have child nodes inside parent,
> > something related to the phandle way ? I grep'd i2c in arch/arm/boot/dts and
> > couldn't find anything of that sort, the way i2c clients are added is:
> >
> > in dtsi file:
> >
> > i2c0: i2c@address {
> >          ...
> > }
> >
> > in dts file:
> > &i2c0 {
> >           stmpe810 {
> >           ........
> >           }
> > }
> >
> > which i believe will be taken care by dtc and will fold client nodes
> > as child nodes
> > of i2c0.
> >
> > @Grant: Please throw some light here :)
> >
> > --
> > viresh

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2012-12-05 13:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-29 14:40 [PATCH V5 1/2] mfd: stmpe: Get rid of irq_invert_polarity Viresh Kumar
     [not found] ` <2dcd7cb4c4022fa24b5328974e4226f5aaf89419.1354199865.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-11-29 14:40   ` [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver Viresh Kumar
     [not found]     ` <121653def4e985b0c1b59045637dd4518f97e73a.1354199865.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-11-30 10:57       ` Samuel Ortiz
2012-11-30 12:45         ` Lee Jones
2012-11-30 13:11           ` Viresh Kumar
2012-11-30 13:20             ` Lee Jones
     [not found]               ` <20121130132036.GA23648-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-30 13:44                 ` Viresh Kumar
2012-11-30 15:45         ` Lee Jones
2012-11-30 19:03           ` Viresh Kumar
2012-12-05 13:03             ` Viresh Kumar
2012-12-05 13:19               ` Lee Jones [this message]
2012-12-05 13:24                 ` Viresh Kumar
2012-12-05 22:42             ` Grant Likely
2012-12-06  1:58               ` Viresh Kumar
2012-12-06  9:50                 ` Lee Jones
     [not found]                   ` <20121206095019.GN2718-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-06  9:56                     ` Viresh Kumar
     [not found]                       ` <CAKohpokNQB6L2vvjmvA7_3KomFXnV9wZ-uBjrfRVuBL=QWgr_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-06 10:11                         ` Lee Jones
2012-12-06 10:19                           ` Viresh Kumar
2012-12-06 10:35                             ` Lee Jones
2012-12-06 10:42                               ` Viresh Kumar
2012-12-06 11:12                                 ` Lee Jones
2012-12-06 11:19                                   ` Viresh Kumar
     [not found]                                     ` <CAKohponrZ8a+=ozXox60nRVBO174Nr=GoSjKkkz7KjLCxd5BhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-06 11:33                                       ` Lee Jones
2012-12-07 13:37                 ` Grant Likely
2012-12-06  2:36               ` Viresh Kumar
2012-12-07 13:44                 ` Grant Likely
2012-12-01 16:49 ` [PATCH V5 1/2] mfd: stmpe: Get rid of irq_invert_polarity Linus Walleij

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=20121205131904.GJ2718@gmail.com \
    --to=lee.jones@linaro.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rabin.vincent@stericsson.com \
    --cc=sameo@linux.intel.com \
    --cc=shiraz.hashim@st.com \
    --cc=spear-devel@list.st.com \
    --cc=vipulkumar.samar@st.com \
    --cc=viresh.kumar@linaro.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 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).