On Sat, Sep 24, 2011 at 1:29 PM, Paul Walmsley <p...@pwsan.com> wrote: > On Fri, 23 Sep 2011, J, KEERTHY wrote: > >> On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley <p...@pwsan.com> wrote: >> >> > On Thu, 22 Sep 2011, Keerthy wrote: >> > >> >> diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c >> >> b/arch/arm/mach-omap2/temp_sensor4460_data.c >> >> new file mode 100644 >> >> index 0000000..2804615 >> >> --- /dev/null >> >> +++ b/arch/arm/mach-omap2/temp_sensor4460_data.c >> > >> > Is there some reason why this shouldn't go into drivers/ in some form? >> >> This is used by mach-omap2. > > Why does something in mach-omap2 need this data?
The scm hwmod is populating the pointer to the register set which is specific to OMAP4460. So i have kept the OMAP4460 specific data file in mach-omap2. > >> >> diff --git a/arch/arm/plat-omap/include/plat/scm.h >> >> b/arch/arm/plat-omap/include/plat/scm.h >> >> new file mode 100644 >> >> index 0000000..47aa38f >> >> --- /dev/null >> >> +++ b/arch/arm/plat-omap/include/plat/scm.h >> > >> > If this is being used by a driver, then this header file should go into >> > the appropriate drivers/ subdirectory. If it is being used by code in >> > arch/arm/mach-omap2, then please use the existing >> > arch/arm/mach-omap2/control.h instead. >> >> The header file has structures used both by drivers/ and mach-omap. >> So kept it in plat-omap. > > The point is, if there are structure definitions and macros that are > only needed by code in drivers/, then those should be split off into a > separate file and placed in drivers/. Similarly, if there are elements of > this file that are only used in mach-omap2/, then those should go into > mach-omap2/control.h. > > About the only part off the top of my head that should go into a > plat-omap header file should be the dev_attr structure. And it's > debatable whether this driver even needs a dev_attr, or whether all > this data should just go into an omap4460_scm.c MFD driver that uses > a bunch of common code for the parts that are shared with 4430, etc. > Do you have any views on this issue? There can be a common omap4_scm.c driver. The temperature sensor is different from OMAP4430 and OMAP4460. So keeping the temperature sensor as omap4460plus. Coming to structure definitions. pdata structure is needed both by mach-omap device file to populate it and also by the driver t extract it. So keeping all of the structure definitions in one header file in plat_omap. My question is which is the ideal place to keep the common structure definition like pdata? Since the temperature sensor does not have a separate hwmod of its own i feel there is a necessity of dev_attr. > > > - Paul -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
