From: "G, Manjunath Kondaiah" <manjugk@ti.com>
To: "Cousson, Benoit" <b-cousson@ti.com>
Cc: "devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt
Date: Tue, 16 Aug 2011 20:32:25 +0530 [thread overview]
Message-ID: <20110816150224.GA22182@manju-desktop> (raw)
In-Reply-To: <20110810162846.GC2091@manju-desktop>
On Wed, Aug 10, 2011 at 09:58:46PM +0530, G, Manjunath Kondaiah wrote:
> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
> > Hi Manju,
> >
> > On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> > >
> > >The omap dt requires new omap hwmod api to be added for in order
> > >to support omap dt.
> >
> > Both the subject and the changelog are misleading. You are not doing
> > any hwmod stuff in it.
> > You are just passing an "of_node" pointer during omap_device_build_ss.
> >
> > The subject should start with OMAP: omap_device: because it does not
> > belong to the DT subsystem.
> > The same comment apply to most patches in that series.
>
> The goal of this patch is to make omap-hwmod ready for dt adaptation hence
> I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
> is passed from dt and it is required for dt build.
>
> And as you mentioned, patch does not do anything related to omap_device.
>
> >
> > >The new api is added and new parameter "np" is added for existing
> > >api.
> >
> > I don't think np is not a super meaningful name. Some more
> > explanation are needed as well.
>
> ok. I can expand it.
>
> >
> > >The users of hwmod api is changed accrodingly.
> >
> > omap_device API + typo.
> >
> > >Build and boot tested on omap3 beagle for both dt and not dt build.
> > >
> > >Signed-off-by: G, Manjunath Kondaiah<manjugk@ti.com>
> > >---
> > > arch/arm/mach-omap2/devices.c | 2 +-
> > > arch/arm/mach-omap2/mcbsp.c | 2 +-
> > > arch/arm/plat-omap/include/plat/omap_device.h | 11 +++++-
> > > arch/arm/plat-omap/omap_device.c | 53 ++++++++++++++++++++++---
> > > 4 files changed, 59 insertions(+), 9 deletions(-)
> > >
> > >diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > >index 458f7be..d7ff1ae 100644
> > >--- a/arch/arm/mach-omap2/devices.c
> > >+++ b/arch/arm/mach-omap2/devices.c
> > >@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
> > > pr_err("could not look up %s\n", oh_name);
> > > }
> > >
> > >- pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> > >+ pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
> > > 0, NULL, 0, 0);
> >
> > OK, maybe that is just me, but in order to extend an API, I'd rather
> > add the new parameter at the end.
>
> I feel it's fine since node pointer is first parameter is all dt api's.
>
> >
> > > WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> > >diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> > >index 7a42f32..98eb95d 100644
> > >--- a/arch/arm/mach-omap2/mcbsp.c
> > >+++ b/arch/arm/mach-omap2/mcbsp.c
> > >@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
> > > (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
> > > count++;
> > > }
> > >- pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> > >+ pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
> > > sizeof(*pdata), omap2_mcbsp_latency,
> > > ARRAY_SIZE(omap2_mcbsp_latency), false);
> > > kfree(pdata);
> > >diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
> > >index 7a3ec4f..5e2424b 100644
> > >--- a/arch/arm/plat-omap/include/plat/omap_device.h
> > >+++ b/arch/arm/plat-omap/include/plat/omap_device.h
> > >@@ -33,6 +33,7 @@
> > >
> > > #include<linux/kernel.h>
> > > #include<linux/platform_device.h>
> > >+#include<linux/of.h>
> > >
> > > #include<plat/omap_hwmod.h>
> > >
> > >@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> > > struct omap_device_pm_latency *pm_lats,
> > > int pm_lats_cnt, int is_early_device);
> > >
> > >-struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
> > >+struct platform_device *omap_device_build_ss(struct device_node *np,
> > >+ const char *pdev_name, int pdev_id,
> > > struct omap_hwmod **oh, int oh_cnt,
> > > void *pdata, int pdata_len,
> > > struct omap_device_pm_latency *pm_lats,
> > > int pm_lats_cnt, int is_early_device);
> > >
> > >+struct platform_device *omap_device_build_dt(struct device_node *np,
> > >+ const char *pdev_name, int pdev_id,
> > >+ struct omap_hwmod *oh, void *pdata,
> > >+ int pdata_len,
> > >+ struct omap_device_pm_latency *pm_lats,
> > >+ int pm_lats_cnt, int is_early_device);
> > >+
> > > void __iomem *omap_device_get_rt_va(struct omap_device *od);
> > >
> > > /* OMAP PM interface */
> > >diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> > >index 7d5e76b..fa49168 100644
> > >--- a/arch/arm/plat-omap/omap_device.c
> > >+++ b/arch/arm/plat-omap/omap_device.c
> > >@@ -85,6 +85,7 @@
> > > #include<linux/clk.h>
> > > #include<linux/clkdev.h>
> > > #include<linux/pm_runtime.h>
> > >+#include<linux/of_device.h>
> > >
> > > #include<plat/omap_device.h>
> > > #include<plat/omap_hwmod.h>
> > >@@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od,
> > > /**
> > > * omap_device_build - build and register an omap_device with one omap_hwmod
> >
> > Need to update the kerneldoc.
> ok.
As these API's are interim API's and we might have alternate setup to handle
hwmod in the coming days, the documentation part will be taken care along with
final solution for hwmod issue.
> >
> > > * @pdev_name: name of the platform_device driver to use
> > >+ * @np: device node pointer for attaching it to of_node pointer
> > > * @pdev_id: this platform_device's connection ID
> > > * @oh: ptr to the single omap_hwmod that backs this omap_device
> > > * @pdata: platform_data ptr to associate with the platform_device
> > >@@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od,
> > > * information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise,
> > > * passes along the return value of omap_device_build_ss().
> > > */
> > >-struct platform_device *omap_device_build(const char *pdev_name, int pdev_id,
> > >+struct platform_device *omap_device_build_dt(struct device_node *np,
> > >+ const char *pdev_name, int pdev_id,
> > > struct omap_hwmod *oh, void *pdata,
> > > int pdata_len,
> > > struct omap_device_pm_latency *pm_lats,
> >
> > That function should not be needed. You have to export
> > omap_device_build_ss, otherwise you will not build any device with
> > multiple hwmods.
> ok.
confused here. All the three API's *_dt/*_ss/*_dt are exported and can be
accessed for single or multiple hwmods. Am I missing anything?
-M
next prev parent reply other threads:[~2011-08-16 15:02 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-09 14:10 [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 01/14] OMAP: omap_device: replace _find_by_pdev() with to_omap_device() G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 02/14] OMAP: omap_device: replace debug/warning/error prints with dev_* macros G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 03/14] OMAP3: beagle: don't touch omap_device internals G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices G, Manjunath Kondaiah
2011-08-10 7:07 ` Jarkko Nikula
2011-08-10 10:15 ` Cousson, Benoit
2011-08-10 16:05 ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 05/14] OMAP: omap_device: remove internal functions from omap_device.h G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 06/14] OMAP: omap_device: when building return platform_device instead of omap_device G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 07/14] ARM: platform_device: pdev_archdata: add omap_device pointer G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 08/14] omap2+: Use Kconfig symbol in Makefile instead of obj-y G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt G, Manjunath Kondaiah
2011-08-10 11:51 ` Cousson, Benoit
2011-08-10 16:28 ` G, Manjunath Kondaiah
2011-08-10 17:11 ` Cousson, Benoit
2011-08-10 18:03 ` G, Manjunath Kondaiah
[not found] ` <CAC63_iSX0cjauOj=CcTABqgSWAgYRE_G7Qio5y2BrpeRnkhEWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-08-10 18:06 ` Cousson, Benoit
2011-08-16 15:02 ` G, Manjunath Kondaiah [this message]
2011-08-09 14:10 ` [RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure G, Manjunath Kondaiah
[not found] ` <1312897232-4792-11-git-send-email-manjugk-l0cyMroinI0@public.gmane.org>
2011-08-10 11:57 ` Cousson, Benoit
2011-08-10 13:16 ` Grant Likely
2011-08-10 16:02 ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers G, Manjunath Kondaiah
2011-08-10 12:36 ` Cousson, Benoit
2011-08-10 16:57 ` G, Manjunath Kondaiah
2011-08-10 17:45 ` Cousson, Benoit
2011-08-16 6:32 ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices G, Manjunath Kondaiah
2011-08-10 12:42 ` Cousson, Benoit
2011-08-10 16:45 ` G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 13/14] dt: omap3: add generic board file for dt support G, Manjunath Kondaiah
2011-08-09 14:10 ` [RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller G, Manjunath Kondaiah
2011-08-10 12:57 ` Cousson, Benoit
2011-08-16 18:44 ` G, Manjunath Kondaiah
2011-08-10 5:26 ` [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support Rajendra Nayak
2011-08-10 5:30 ` G, Manjunath Kondaiah
2011-08-10 5:39 ` Rajendra Nayak
2011-08-10 6:28 ` G, Manjunath Kondaiah
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=20110816150224.GA22182@manju-desktop \
--to=manjugk@ti.com \
--cc=b-cousson@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.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).