> >>> -----Original Message-----
> >>> From: [email protected]
> >>> [mailto:[email protected]] On Behalf Of Thara Gopinath
> >>> Sent: Wednesday, October 27, 2010 9:41 PM
> >>> To: [email protected]
> >>> Cc: [email protected]; [email protected]; Cousson,
> >>> Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
> >>> Subject: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
> >>>
> >>> SmartReflex modules do adaptive voltage control for real-time
> >>> voltage adjustments. With Smartreflex the power supply voltage
> >>> can be adapted to the silicon performance(manufacturing process,
> >>> temperature induced performance, age induced performance etc).
> >>>
> >>> There are differnet classes of smartreflex implementation.
> >>> Class-0: Manufacturing Test Calibration
> >>> Class-1: Boot-Time Software Calibration
> >>> Class-2: Continuous Software Calibration
> >>> Class-3: Continuous Hardware Calibration
> >>> Class-4: Fully Integrated Power Management
> >>>
> >>> OMAP3 has two smartreflex modules one associated with VDD MPU and the
> >>> other associated with VDD CORE.
> >>> This patch adds support for smartreflex driver. The driver
> >>> is designed
> >>> for Class-1 , Class-2 and Class-3 support and is a platform driver.
> >>> Smartreflex driver can be enabled through a Kconfig option
> >>> "SmartReflex support" under "System type"->"TI OMAP
> >>> implementations" menu.
> >>>
> >>> Smartreflex autocompensation feature can be enabled runtime through
> >>> a debug fs option.
> >>> To enable smartreflex autocompensation feature
> >>> echo 1 > /debug/voltage/vdd_<X>/smartreflex/autocomp
> >>> To disable smartreflex autocompensation feature
> >>> echo 0 > /debug/voltage/vdd_<X>/smartreflex/autocomp
> >>>
> >>> where X can be mpu, core , iva etc.
> >>>
> >>> This patch contains code originally in linux omap pm branch.
> >>> Major contributors to this driver are
> >>> Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
> >>> Nishant Menon, Kevin Hilman.
> >>>
> >>> Signed-off-by: Thara Gopinath <[email protected]>
> >>> ---
> >>> arch/arm/mach-omap2/Makefile | 1 +
> >>> arch/arm/mach-omap2/smartreflex.c | 975
> >>> +++++++++++++++++++++++++
> >>> arch/arm/plat-omap/Kconfig | 36 +
> >>> arch/arm/plat-omap/include/plat/smartreflex.h | 271 +++++++
> >>> 4 files changed, 1283 insertions(+), 0 deletions(-)
> >>> create mode 100644 arch/arm/mach-omap2/smartreflex.c
> >>> create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
> >>>
> >>
> >><<snip>>
> >>
> >>> +static int __init omap_sr_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct omap_sr *sr_info = kzalloc(sizeof(struct
> >>> omap_sr), GFP_KERNEL);
> >>> + struct omap_device *odev = to_omap_device(pdev);
> >>
> >>Patch3 should be ordered before patch2 in your series. Otherwise,
> >>this would fail during a git-bisect.
>
> Again why ?? All patches individually compile and boot.
omap_device_build() for this device is being done in the next patch.
Hence I gave this input. But I believe that this does not harm because
the probe would not get called. Correct me if I am wrong.
> >>
> >>> + struct omap_sr_data *pdata = pdev->dev.platform_data;
> >>> + struct resource *mem, *irq;
> >>> + struct dentry *vdd_dbg_dir, *dbg_dir;
> >>> + int ret = 0;
> >>> +
> >>> + if (!sr_info) {
> >>> + dev_err(&pdev->dev, "%s: unable to allocate sr_info\n",
> >>> + __func__);
> >>> + return -ENOMEM;
> >>> + }
> >>> +
> >>> + if (!pdata) {
> >>> + dev_err(&pdev->dev, "%s: platform data
> >>> missing\n", __func__);
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >>> + if (!mem) {
> >>> + dev_err(&pdev->dev, "%s: no mem resource\n", __func__);
> >>> + ret = -ENODEV;
> >>> + goto err_free_devinfo;
> >>> + }
> >>> +
> >>> + irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> >>> +
> >>> + pm_runtime_enable(&pdev->dev);
> >>> +
> >>> + sr_info->pdev = pdev;
> >>> + sr_info->srid = pdev->id;
> >>> + sr_info->voltdm = pdata->voltdm;
> >>> + sr_info->autocomp_active = false;
> >>> + sr_info->ip_type = odev->hwmods[0]->class->rev;
> >>
> >>I am not sure if it is okay to get hwmods-info in the driver.
> >>To avoid too many indirections, it can be obtained before
> >>omap_device_build() of the device and passed to the driver.
> mmm. yep we could do it also. Maybe Kevin/Benoit needs to confirm the
> correct way of doing this.
Okay. We will wait.
>
> Regards
> Thara
> >>
> >>> + sr_info->base = ioremap(mem->start, resource_size(mem));
> >>> + if (!sr_info->base) {
> >>> + dev_err(&pdev->dev, "%s: ioremap fail\n", __func__);
> >>> + ret = -ENOMEM;
> >>> + goto err_release_region;
> >>> + }
> >>
> >><<snip>>
> >>
> >>-V Charulatha
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
