All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexander Shiyan" <shc_work@mail.ru>
To: "Dong Aisheng" <dong.aisheng@linaro.org>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	linux-kernel@vger.kernel.org,
	"Samuel Ortiz" <sameo@linux.intel.com>,
	"Mark Brown" <broonie@opensource.wolfsonmicro.com>
Subject: Re[2]: [PATCH v3] mfd: syscon: Add non-DT support
Date: Tue, 19 Feb 2013 11:03:01 +0400	[thread overview]
Message-ID: <1361257381.497560655@f376.mail.ru> (raw)
In-Reply-To: 201302181602.47157.arnd@arndb.de

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 4645 bytes --]

Hello.

Strange, but I not received an original answer from Arnd, have only this mail.

...
> >> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> >> index 4a7ed5a..3c0abcb 100644
> >> --- a/drivers/mfd/syscon.c
> >> +++ b/drivers/mfd/syscon.c
> >
> > Hi Alexander,
> >
> >>  struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
> >>  {
> >>       struct device_node *syscon_np;
> >>       struct regmap *regmap;
> >> +     struct syscon *syscon;
> >> +     struct device *dev;
> >>
> >>       syscon_np = of_find_compatible_node(NULL, NULL, s);
> >> -     if (!syscon_np)
> >> +     if (syscon_np) {
> >> +             regmap = syscon_node_to_regmap(syscon_np);
> >> +             of_node_put(syscon_np);
> >> +
> >> +             return regmap;
> >> +     }
> >> +
> >> +     /* Fallback to search by id_entry.name string */
> >> +     dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
> >> +                              syscon_match_id);
> >> +     if (!dev)
> >>               return ERR_PTR(-ENODEV);
> >>
> >> -     regmap = syscon_node_to_regmap(syscon_np);
> >> -     of_node_put(syscon_np);
> >> +     syscon = dev_get_drvdata(dev);
> >>
> >> -     return regmap;
> >> +     return syscon->regmap;
> >>  }
> >>  EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> >
> > Since you are not actually comparing the "compatible" property here,
> > I would suggest adding another function here,
> 
> Yes, i also think like that.

In this case we should provide two paths for drivers which can work as with DT
and without DT. In my case we can use platform_device_id.name field with
"compatible" string. My way in this case is transparency for driver which is
using "syscon".

> 
> > something like
> > syscon_regmap_lookup_by_pdevname() that you can use in device
> > drivers that are not DT-enabled.
> 
> IMHO i would like syscon_dev_to_regmap, then we do not need to
> care in case pdevname changes.
> See:
> http://www.gossamer-threads.com/lists/linux/kernel/1675210#1675210
> What do you think?

For me, I still do not understand how we get syscon_dev from driver.

> > I would also recommend enclosing
> > that function in #ifdef CONFIG_ATAGS.
> >
> > Which code do you have in mind that would call this anyway?
> > The changeset description does not really explain what ATAG
> > boot support in syscon is good for.
> >
> >> +     if (IS_ENABLED(CONFIG_OF) && np) {
> >> +             syscon->base = of_iomap(np, 0);
> >> +             if (!syscon->base)
> >> +                     return -EADDRNOTAVAIL;
> >> +
> >> +             res = &res_of;
> >> +             ret = of_address_to_resource(np, 0, res);
> >> +             if (ret) {
> >> +                     iounmap(syscon->base);
> >> +                     return ret;
> >> +             }
> >> +     } else {
> >> +             res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> +             if (!res)
> >> +                     return -ENOENT;
> >> +
> >> +             if (!devm_request_mem_region(dev, res->start,
> >> +                                          resource_size(res),
> >> +                                          dev_name(&pdev->dev)))
> >> +                     return -EBUSY;
> >> +
> >> +             syscon->base = ioremap(res->start, resource_size(res));
> >> +             if (!syscon->base)
> >> +                     return -EADDRNOTAVAIL;
> >> +     }
> >
> > These two code paths look equivalent. Why not always use the second
> > one? Also, you might want to convert this to devm_ioremap_resource()
> > to simplify the code in the process.
> >
> 
> These two code paths have a slight difference.
> The path1 does not request the mem region, the main reason of that is we meet
> some devices register ranges used as syscon maybe overlapped with
> other exist drivers.
> e.g imx6q.dtsi
> The gpr is a few registers contained in iomuxc.
> gpr: iomuxc-gpr@020e0000 {
>         compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
>         reg = <0x020e0000 0x38>;
> };
> 
> iomuxc: iomuxc@020e0000 {
>         compatible = "fsl,imx6q-iomuxc";
>         reg = <0x020e0000 0x4000>;
> ...
> };
> 
> The iomuxc already has a pinctrl driver, so there are conflicts if both
> request the same mem region.
> 
> So i wonder maybe we also do not need request mem region in non-dt case,
> then we can only  use second code path.

So, you suggest completely remove CONFIG_OF-dependent code from "probe"?
I am not a guru in DT, is it will work correct?

---
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

  parent reply	other threads:[~2013-02-19  7:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18 14:42 [PATCH v3] mfd: syscon: Add non-DT support Alexander Shiyan
2013-02-18 16:02 ` Arnd Bergmann
2013-02-19  5:52   ` Dong Aisheng
2013-02-19  7:03   ` Alexander Shiyan [this message]
2013-02-19  7:55     ` Re[2]: " Dong Aisheng
2013-02-19  8:02       ` Dong Aisheng
2013-02-19  8:56     ` Re[4]: " Alexander Shiyan
2013-02-19  9:58       ` Dong Aisheng
2013-02-19 10:54       ` Re[6]: " Alexander Shiyan
2013-02-20  5:20         ` Dong Aisheng
2013-02-20  5:41         ` Re[8]: " Alexander Shiyan
2013-02-20  6:01           ` Dong Aisheng
2013-02-20 10:06           ` Arnd Bergmann
2013-02-20 11:05             ` Dong Aisheng
2013-02-20 11:14               ` Arnd Bergmann
2013-02-20 11:28                 ` Dong Aisheng
2013-02-20 12:16                   ` Arnd Bergmann
2013-02-20 12:47                 ` Re[10]: " Alexander Shiyan
2013-02-20 15:00                   ` Arnd Bergmann
2013-02-20 16:06                     ` Re[12]: " Alexander Shiyan
2013-02-20 17:16                       ` Arnd Bergmann
2013-02-20 17:27                         ` Re[14]: " Alexander Shiyan
2013-02-20 21:27                           ` Arnd Bergmann
2013-02-21 15:27                             ` Re[16]: " Alexander Shiyan
2013-02-19 10:49     ` Re[2]: " Arnd Bergmann

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=1361257381.497560655@f376.mail.ru \
    --to=shc_work@mail.ru \
    --cc=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=dong.aisheng@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    /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.