RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.

[Varadarajan, Charulatha]

> >>> >>> -Original Message-
> >>> >>> From: linux-omap-ow...@vger.kernel.org
> >>> >>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara
> Gopinath
> >>> >>> Sent: Wednesday, October 27, 2010 9:41 PM
> >>> >>> To: linux-omap@vger.kernel.org
> >>> >>> Cc: p...@pwsan.com; khil...@deeprootsystems.com; 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_/smartreflex/autocomp
> >>> >>> To disable smartreflex autocompensation feature
> >>> >>>   echo 0 > /debug/voltage/vdd_/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 
> >>> >>> ---
> >>> >>>  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
> >>> >>>
> >>> >>
> >>> >><>
> >>> >>
> >>> >>> +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.
> 
> Exactly probe will not get called. So I do not think the patch ordering
> needs to change.

Okay. But for the other patch, I think it is required to reorder the patch 
series because the oh data is accessed in omap_device_build() and 
omap_hwmod_each_by_class(), but oh data is not filled by then.

> 
> Regards
> Thara
--
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

RE: [Patch v3] OMAP: AM3517/05: Add craneboard support

[Srinath R]

-Original Message-
From: Premi, Sanjeev [mailto:pr...@ti.com] 
Sent: Thursday, October 28, 2010 7:47 PM
To: srin...@mistralsolutions.com; linux-omap@vger.kernel.org
Cc: Kridner, Jason; t...@atomide.com; khil...@deeprootsystems.com; Menon,
Nishanth; nagen...@mistralsolutions.com; ume...@mistralsolutions.com
Subject: RE: [Patch v3] OMAP: AM3517/05: Add craneboard support

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
> srin...@mistralsolutions.com
> Sent: Thursday, October 28, 2010 6:59 PM
> To: linux-omap@vger.kernel.org
> Cc: Kridner, Jason; t...@atomide.com; 
> khil...@deeprootsystems.com; Menon, Nishanth; 
> nagen...@mistralsolutions.com; ume...@mistralsolutions.com; Srinath
> Subject: [Patch v3] OMAP: AM3517/05: Add craneboard support
> 

[snip]

> +MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")

Compared against AM3715, I see these missing:
.phys_io= 0x4800,
.io_pg_offst= ((0xd800) >> 18) & 0xfffc,

Are these not required?

[Srintah] According to commit ID de01f1735c9a8c00b3625507c7327a1f0b347b7b,
io_pg_offst and phys_io members are 
no more required in struct machine_desc

> + .boot_params= 0x8100,
> + .map_io = omap3_map_io,
> + .reserve= omap_reserve,
  
Check for mix of space & tabs here.

[Srintah] Sure, I will update and re-submit patch 

~sanjeev

> + .init_irq   = am3517_crane_init_irq,
> + .init_machine   = am3517_crane_init,
> + .timer  = &omap_timer,
> +MACHINE_END
> diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
> b/arch/arm/plat-omap/include/plat/uncompress.h
> index 9036e37..229fbf2 100644
> --- a/arch/arm/plat-omap/include/plat/uncompress.h
> +++ b/arch/arm/plat-omap/include/plat/uncompress.h
> @@ -145,6 +145,7 @@ static inline void 
> __arch_decomp_setup(unsigned long arch_id)
>   /* omap3 based boards using UART3 */
>   DEBUG_LL_OMAP3(3, cm_t35);
>   DEBUG_LL_OMAP3(3, cm_t3517);
> + DEBUG_LL_OMAP3(3, craneboard);
>   DEBUG_LL_OMAP3(3, igep0020);
>   DEBUG_LL_OMAP3(3, igep0030);
>   DEBUG_LL_OMAP3(3, nokia_rx51);
> -- 
> 1.7.1.226.g770c5
> 
> --
> 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
> =

--
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

RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.

[Gopinath, Thara]

>>-Original Message-
>>From: Varadarajan, Charulatha
>>Sent: Friday, October 29, 2010 10:23 AM
>>To: Gopinath, Thara; linux-omap@vger.kernel.org
>>Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
>>Vishwanath; Sawant, Anand
>>Subject: RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
>>
>>
>>> >>> -Original Message-
>>> >>> From: linux-omap-ow...@vger.kernel.org
>>> >>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara Gopinath
>>> >>> Sent: Wednesday, October 27, 2010 9:41 PM
>>> >>> To: linux-omap@vger.kernel.org
>>> >>> Cc: p...@pwsan.com; khil...@deeprootsystems.com; 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_/smartreflex/autocomp
>>> >>> To disable smartreflex autocompensation feature
>>> >>> echo 0 > /debug/voltage/vdd_/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 
>>> >>> ---
>>> >>>  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
>>> >>>
>>> >>
>>> >><>
>>> >>
>>> >>> +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.

Exactly probe will not get called. So I do not think the patch ordering
needs to change. 

Regards
Thara
--
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

RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.

[Varadarajan, Charulatha]

> >>> -Original Message-
> >>> From: linux-omap-ow...@vger.kernel.org
> >>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara Gopinath
> >>> Sent: Wednesday, October 27, 2010 9:41 PM
> >>> To: linux-omap@vger.kernel.org
> >>> Cc: p...@pwsan.com; khil...@deeprootsystems.com; 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_/smartreflex/autocomp
> >>> To disable smartreflex autocompensation feature
> >>>   echo 0 > /debug/voltage/vdd_/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 
> >>> ---
> >>>  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
> >>>
> >>
> >><>
> >>
> >>> +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;
> >>> + }
> >>
> >><>
> >>
> >>-V Charulatha
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
t

RE: OMAP3 low power mode broken on l-o

[Shilimkar, Santosh]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Jean Pihet
> Sent: Friday, October 29, 2010 2:11 AM
> To: linux-omap@vger.kernel.org
> Cc: Kevin Hilman
> Subject: OMAP3 low power mode broken on l-o
> 
> Hi,
> 
> The low power mode on the latest l-o master branch is broken, so I
> investigated a bit. Here are the results. This has been tested on
> OMAP3EVM and Beagleboard.
> 
> The problem is that the CORE does not reach the desired mode (RET,
> OFF). It is caused by the I2C1 fclk that is left enabled at suspend
> time.
> Extra printks has been added in the clock enable and disable functions
> for I2C and a stack dump has been added in the suspend path if the
> clock is still enabled, cf. log below.
> 
> In the devices suspend sequence the RTC gets suspended, which triggers
> a read of the TWL RTC through the I2C bus, which in turn enables the
> I2C1 fclk. That clock is only disabled on devices resume.
> 
> I am guessing this is linked to the recent changes in the I2C for HWMOD
> support.
> What is the correct fix to have the I2C modules correctly shut off
> before the suspend?
> 
> Any thoughts?
Looks like get_sync / put_sync miss-match has re-appeared again which leads
to I2C clocks are not getting cut.

Regards,
Santosh


--
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

RE: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.

[Varadarajan, Charulatha]

> -Original Message-
> From: Gopinath, Thara
> Sent: Thursday, October 28, 2010 8:56 PM
> To: Varadarajan, Charulatha; linux-omap@vger.kernel.org
> Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
> Vishwanath; Sawant, Anand
> Subject: RE: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
> 
> 
> 
> >>-Original Message-
> >>From: Varadarajan, Charulatha
> >>Sent: Thursday, October 28, 2010 11:09 AM
> >>To: Gopinath, Thara; linux-omap@vger.kernel.org
> >>Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
> Sripathy,
> >>Vishwanath; Sawant, Anand
> >>Subject: RE: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
> >>
> >>Thara,
> >>
> >>> -Original Message-
> >>> From: linux-omap-ow...@vger.kernel.org
> >>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
> >>> Sent: Wednesday, October 27, 2010 9:41 PM
> >>> To: linux-omap@vger.kernel.org
> >>> Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
> >>> Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
> >>> Subject: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
> >>>
> >>> This patch adds support for device registration of various
> >>> smartreflex module present in the system. This patch introduces
> >>> the platform data for smartreflex devices which include
> >>> the efused and test n-target vaules, module enable/disable
> >>> pointers and a parameter to indicate whether smartreflex
> >>> autocompensation needs to be enabled on init or not.
> >>> Currently auocompensation is enabled on init by default
> >>> for OMAP3430 ES3.1 chip.
> >>>
> >>> Signed-off-by: Thara Gopinath 
> >>> ---
> >>>  arch/arm/mach-omap2/Makefile|2 +-
> >>>  arch/arm/mach-omap2/sr_device.c |  177
> >>> +++
> >>>  2 files changed, 178 insertions(+), 1 deletions(-)
> >>>  create mode 100644 arch/arm/mach-omap2/sr_device.c
> >>>
> >>
> >><>
> >>
> >>> +
> >>> +static int sr_dev_init(struct omap_hwmod *oh, void *user)
> >>
> >>Since *user is unused, you may rename it to *unused
> 
> Ok will do.
> 
> >>
> >>> +{
> >>> + struct omap_sr_data *sr_data;
> >>> + struct omap_sr_dev_data *sr_dev_data;
> >>> + struct omap_device *od;
> >>> + char *name = "smartreflex";
> >>> + static int i;
> >>> +
> >>> + sr_data = kzalloc(sizeof(struct omap_sr_data), GFP_KERNEL);
> >>> + if (!sr_data) {
> >>> + pr_err("%s: Unable to allocate memory for %s
> >>> sr_data.Error!\n",
> >>> + __func__, oh->name);
> >>> + return -ENOMEM;
> >>> + }
> >>> +
> >>> + sr_dev_data = (struct omap_sr_dev_data *)oh->dev_attr;
> >>> + if (unlikely(!sr_dev_data)) {
> >>> + pr_err("%s: dev atrribute is NULL\n", __func__);
> >>> + goto exit;
> >>> + }
> >>> +
> >>> + /*
> >>> +  * OMAP3430 ES3.1 chips by default come with Efuse burnt
> >>> +  * with parameters required for full functionality of
> >>> +  * smartreflex AVS feature like ntarget values , sennenable
> >>> +  * and senpenable. So enable the SR AVS feature during boot up
> >>> +  * itself if it is a OMAP3430 ES3.1 chip.
> >>> +  */
> >>> + sr_data->enable_on_init = false;
> >>> + if (cpu_is_omap343x())
> >>> + if (omap_rev() == OMAP3430_REV_ES3_1)
> >>> + sr_data->enable_on_init = true;
> >>> +
> >>> + sr_data->voltdm =
> >>> omap_voltage_domain_lookup(sr_dev_data->vdd_name);
> >>> + if (IS_ERR(sr_data->voltdm)) {
> >>> + pr_err("%s: Unable to get voltage domain
> >>> pointer for VDD %s\n",
> >>> + __func__, sr_dev_data->vdd_name);
> >>> + goto exit;
> >>> + }
> >>> +
> >>> + sr_dev_data->volts_supported = omap_voltage_get_volttable(
> >>> + sr_data->voltdm, &sr_dev_data->volt_data);
> >>> + if (!sr_dev_data->volts_supported) {
> >>> + pr_warning("%s: No Voltage table registerd fo VDD%d."
> >>> + "Something really wrong\n\n", __func__, i + 1);
> >>> + goto exit;
> >>> + }
> >>> +
> >>> + sr_set_nvalues(sr_dev_data, sr_data);
> >>> +
> >>> + od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
> >>> +omap_sr_latency,
> >>> +ARRAY_SIZE(omap_sr_latency), 0);
> >>
> >>Patch 4 should come before patch 3 in the series. Otherwise, this
> >>would fail during a git-bisect.
> 
> Why?? All patches individually compile and boot.

Oh data for SR is filled only in patch 4 but oh is being used here.
Wouldn't that create a problem?

> 
> >>
> >>> + if (IS_ERR(od))
> >>> + pr_warning("%s: Could not build omap_device for
> >>> %s: %s.\n\n",
> >>> + __func__, name, oh->name);
> >>
> >>Return error.
> >>
> >>> +exit:
> >>> + i++;
> >>> + kfree(sr_data);
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int __init omap_devinit_smartreflex(void)
> >>> +{
> >>> + return omap_hwmod_for_each_by_class("smartreflex",
> >>> sr_dev_init, NULL);
> >>> +}
> >>> +device_initcall(omap_devinit_smart

Re: [PATCH 5/7] omap:mailbox-resolve multiple receiver problem

[Omar Ramirez Luna]

On 10/14/2010 9:13 PM, Kanigeri, Hari wrote:

OMAP4 shares one interrupt line for all the mailbox instances.
The ISR is handling only the mailbox instance that was registered last.


This shouldn't be needed, request_irq is being called with IRQF_SHARED 
flag and different device ids, so if a message arrives it fires an 
interrupt handler for each of the callers to request_irq and since the 
device id is actually a pointer to a mbox struct, the different users 
can be detected and signaled without looping through the "mboxes" list.


Also using "mboxes" list, will try to check for all registered mailboxes 
during probe, which might not be the same as the actual users (the ones 
that have called omap_mbox_get) and then unnecesary check their irq 
statuses if an interrupt arrives.


I think this patch can be dropped.

Regards,

Omar
--
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

Re: [PATCH 6/7] omap:mailbox-add notification support for multiple readers

[Omar Ramirez Luna]

Hi,

On 10/14/2010 9:13 PM, Hari Kanigeri wrote:

@@ -252,41 +253,39 @@ static int omap_mbox_startup(struct omap_mbox *mbox)

...

+   if (!mbox->use_count++) {
+   ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
+   mbox->name, mbox);

...

@@ -296,29 +295,36 @@ fail_alloc_txq:

...

  static void omap_mbox_fini(struct omap_mbox *mbox)
  {
+   if (!--mbox->use_count) {
+   tasklet_kill(&mbox->txq->tasklet);
+   flush_work(&mbox->rxq->work);
+   mbox_queue_free(mbox->txq);
+   mbox_queue_free(mbox->rxq);
+   }
+
+   if (likely(mbox->ops->shutdown)) {
+   if (!--mbox_configured) {
+   free_irq(mbox->irq, mbox);


Above hunks will create an imbalance of free_irq, as request_irq can be 
called per registered mailbox and free_irq is only done for the last 
caller releasing the mailbox handle.


e.g.: mbox-1, mbox-N will request a shared irq on the same interrupt 
line, but only the last caller of omap_mbox_put will free its irq, 
leaving the other one there.


This can be fixed if the free is moved to be executed within the 
following block:


if (!--mbox->use_count) {
...
free_irq(mbox->irq, mbox);
}

Regards,

Omar
--
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

OMAP3 low power mode broken on l-o

[Jean Pihet]

Hi,

The low power mode on the latest l-o master branch is broken, so I
investigated a bit. Here are the results. This has been tested on
OMAP3EVM and Beagleboard.

The problem is that the CORE does not reach the desired mode (RET,
OFF). It is caused by the I2C1 fclk that is left enabled at suspend
time.
Extra printks has been added in the clock enable and disable functions
for I2C and a stack dump has been added in the suspend path if the
clock is still enabled, cf. log below.

In the devices suspend sequence the RTC gets suspended, which triggers
a read of the TWL RTC through the I2C bus, which in turn enables the
I2C1 fclk. That clock is only disabled on devices resume.

I am guessing this is linked to the recent changes in the I2C for HWMOD support.
What is the correct fix to have the I2C modules correctly shut off
before the suspend?

Any thoughts?

Regards,
Jean

=== Boot messages ===
...
[2.284698] regulator_init_complete: incomplete constraints, leaving VMMC1 on
[2.292724] *** Enable clock i2c1_fck
[2.296875] *** Disable clock i2c1_fck
[2.300964] *** Enable clock i2c1_fck
[2.305206] *** Disable clock i2c1_fck
[2.309204] *** Enable clock i2c1_fck
[2.313537] *** Disable clock i2c1_fck
[2.317535] twl_rtc twl_rtc: setting system clock to 2000-01-01
02:12:33 UTC (946692753)
[2.330841] Freeing init memory: 2296K

Please press Enter to activate this console.
/ #

=== Suspend messages ===

/ # echo mem > /sys/power/state
[   11.517578] PM: Syncing filesystems ... done.
[   11.529693] Freezing user space processes ... (elapsed 0.02 seconds) done.
[   11.557861] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[   11.590728] Suspending console(s) (use no_console_suspend to debug)
[   11.602478] *** Enable clock i2c1_fck
[   11.602539] [] (unwind_backtrace+0x0/0xe4) from
[] (clk_enable+0x7c/0xac)
[   11.602569] [] (clk_enable+0x7c/0xac) from []
(_enable_clocks+0x18/0x68)
[   11.602630] [] (_enable_clocks+0x18/0x68) from
[] (_omap_hwmod_enable+0x78/0x)
[   11.602661] [] (_omap_hwmod_enable+0x78/0x150) from
[] (omap_hwmod_enable+0x2)
[   11.602691] [] (omap_hwmod_enable+0x28/0x3c) from
[] (omap_device_enable_hwmo)
[   11.602722] [] (omap_device_enable_hwmods+0x1c/0x34) from
[] (_omap_device_ac)
[   11.602752] [] (_omap_device_activate+0x5c/0xf0) from
[] (omap_device_enable+)
[   11.602813] [] (omap_device_enable+0x54/0x80) from
[] (omap_pm_runtime_resume)
[   11.602844] [] (omap_pm_runtime_resume+0x20/0x48) from
[] (__pm_runtime_resum)
[   11.602874] [] (__pm_runtime_resume+0x240/0x30c) from
[] (pm_runtime_resume+0)
[   11.602935] [] (pm_runtime_resume+0x20/0x34) from
[] (omap_i2c_unidle+0x2c/0x)
[   11.602966] [] (omap_i2c_unidle+0x2c/0x17c) from
[] (omap_i2c_xfer+0x20/0x324)
[   11.602996] [] (omap_i2c_xfer+0x20/0x324) from
[] (i2c_transfer+0xc4/0x114)
[   11.603027] [] (i2c_transfer+0xc4/0x114) from
[] (twl_i2c_read+0xe0/0x12c)
[   11.603057] [] (twl_i2c_read+0xe0/0x12c) from
[] (twl_rtc_read_u8+0x24/0x4c)
[   11.603088] [] (twl_rtc_read_u8+0x24/0x4c) from
[] (twl_rtc_read_time+0x18/0x)
[   11.603118] [] (twl_rtc_read_time+0x18/0xd4) from
[] (rtc_read_time+0x64/0x78)
[   11.603179] [] (rtc_read_time+0x64/0x78) from
[] (rtc_suspend+0x44/0x8c)
[   11.603210] [] (rtc_suspend+0x44/0x8c) from []
(legacy_suspend+0x2c/0x64)
[   11.603240] [] (legacy_suspend+0x2c/0x64) from
[] (__device_suspend+0x7c/0x12)
[   11.603271] [] (__device_suspend+0x7c/0x12c) from
[] (dpm_suspend_start+0x320)
[   11.603302] [] (dpm_suspend_start+0x320/0x458) from
[] (suspend_devices_and_e)
[   11.603332] [] (suspend_devices_and_enter+0x48/0x200)
from [] (enter_state+0x)
[   11.603363] [] (enter_state+0xbc/0x120) from []
(state_store+0xa4/0xb8)
[   11.603424] [] (state_store+0xa4/0xb8) from []
(kobj_attr_store+0x18/0x1c)
[   11.603454] [] (kobj_attr_store+0x18/0x1c) from
[] (sysfs_write_file+0x10c/0x)
[   11.603485] [] (sysfs_write_file+0x10c/0x144) from
[] (vfs_write+0xb0/0x128)
[   11.603515] [] (vfs_write+0xb0/0x128) from []
(sys_write+0x3c/0x68)
[   11.603576] [] (sys_write+0x3c/0x68) from []
(ret_fast_syscall+0x0/0x3c)
[   11.611358] PM: suspend of devices complete after 9.674 msecs
[   11.613006] PM: late suspend of devices complete after 1.647 msecs
[   11.613098] Disabling non-boot CPUs ...
[   12.764709] Powerdomain (core_pwrdm) didn't enter target state 1
[   12.764739] Could not enter target state in pm_suspend
[   12.765075] PM: early resume of devices complete after 0.152 msecs
[   12.771789] PM: resume of devices complete after 6.317 msecs
[   12.775695] *** Disable clock i2c1_fck
[   13.100555] *** Enable clock i2c1_fck
[   13.105010] *** Disable clock i2c1_fck
[   13.109222] *** Enable clock i2c1_fck
[   13.113403] *** Disable clock i2c1_fck
[   13.118469] Restarting tasks ... done.
/ #
--
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-inf

Re: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Russell King - ARM Linux]

On Wed, Oct 27, 2010 at 11:19:47AM +0300, Felipe Contreras wrote:
> Yes, but this has to be done on every library/app that is using the dsp.
> It's much easier to do it on kernel side.
> 
> Besides, at least on gst-dsp we want it to work for _all_ bridge
> versions, so it would be:
> 
> @@ -829,7 +829,9 @@ struct map_mem {
> void *proc_handle;
> void *mpu_addr;
> unsigned long size;
> +#if DSP_API >= 3
> void *req_addr;
> +#endif
> void **ret_map_addr;
> unsigned long attr;
>  };

This thread is getting really stupid.  There is a process for changing
the arguments to ioctl.

The first thing is that ioctl numbers are supposed to be defined in a
standard form - using _IO(), _IOR(), _IOW() and _IOWR().  Amongst the
things that these macros take is the structure which is being passed.

What this means is that the ioctl number generated by these macros is
directly related to the size of the structure.  This immediately gives
a way to deal with a limited set of changes to the structure.

The steps are as follows:

1. Rename the structure and all uses of it from "struct map_mem" to
   "struct old_map_mem"
2. Rename the ioctl definition names and all uses to have an OLD prefix.

So at this stage, the original ioctl number and structure are still
present, and importantly are unchanged except by name.

3. Add the new "struct map_mem".
4. Add the new ioctl name definition using "struct map_mem" to identify
   it.
5. Implement the new ioctl number.  Optionally, implement the old ioctl
   functionality via the new implementation if this is appropriate - but
   make sure that the old ioctl still works.
6. arrange for users of the old ioctl to receive a warning that it's
   deprecated.

This allows existing userspace to continue working, but with warnings so
that people know that they need to rebuild their libraries against the
new structures.

There's no need for a DSP_API define using this method, provided you
don't end up with these structures shrinking and then re-growing back
to a size that they were before.
--
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

RE: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Guzman Lugo, Fernando]

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] 
> Sent: Wednesday, October 27, 2010 3:20 AM
> To: Guzman Lugo, Fernando
> Cc: Felipe Contreras; gre...@suse.de; hiroshi.d...@nokia.com; 
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; 
> linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/8] staging: tidspbridge - remove 
> req_addr from proc_map
> 
> On Tue, Oct 26, 2010 at 11:39 PM, Guzman Lugo, Fernando 
>  wrote:
> >> fernando.l...@ti.com wrote:
> >> > > fernando.l...@ti.com wrote:
> >> > > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> >> > > > >  wrote:
> >> > > > > > The device address is assigned by tidspbridge no need for
> >> > > > > that parameter anymore.
> >> > > > > >
> >> > > > > > Signed-off-by: Fernando Guzman Lugo 
> >> > > > >
> >> > > > > This would break the API with user-space, right?
> >> > > >
> >> > > > Yes, user-space needs to be changed accordingly.
> >> > >
> >> > > Wouldn't it make sense to avoid stuffing so many 
> changes at once 
> >> > > including ABI breakage?
> >> > >
> >> > > Does user-space really _needs_ to be changed? Can't you
> >> just ignore
> >> > > that argument?
> >> >
> >> > Actually, I had a previous version of that patch where I
> >> only Ignored
> >> > that paramteter. But after thinking again and seeing How
> >> the long time
> >> > ago depreacted function are still there I Removed the 
> parameter in 
> >> > order to force apps to make the change.
> >>
> >> Again, can we concentrate on first getting this thing to work?
> >
> > If to make it work for 37 the iommu migration patch will be revert 
> > These set of patches will have to wait until the patches are merged 
> > Again. So the dspbridge would be "fix" first a then the 
> patches would 
> > Be merged.
> 
> I couldn't parse this correctly, but yes, I think.
> 
> >> We can think on breaking things again later.
> >>
> >> > You can ignore that argument at API level, so all users of
> >> the API not
> >> > need to have change (in that momment). That should be 
> Only few line 
> >> > change.
> >>
> >> Yes, that's what I'm proposing.
> >
> > I meant userspace api or library level:
> > Example:
> >
> > Dsp_proc_map(proc, mpu_addr, req_addr, *dsp_addr, attr) { ...
> >        struct proc_map args = {
> >                .map_addr = mpu_addr;
> >                /* ignore req_addr */
> >                .dsp_addr = dsp_addr;
> >                .attr = attr;
> >        }
> >
> >        ret = ioctl(handle, PROCMAP_CMD, args) ...
> > }
> 
> Yes, but this has to be done on every library/app that is 
> using the dsp.
> It's much easier to do it on kernel side.
> 
> Besides, at least on gst-dsp we want it to work for _all_ 
> bridge versions, so it would be:
> 
> @@ -829,7 +829,9 @@ struct map_mem {
> void *proc_handle;
> void *mpu_addr;
> unsigned long size;
> +#if DSP_API >= 3
> void *req_addr;
> +#endif
> void **ret_map_addr;
> unsigned long attr;
>  };
> @@ -838,7 +840,9 @@ bool dsp_map(int handle,
> void *proc_handle,
> void *mpu_addr,
> unsigned long size,
> void *req_addr,
> void *ret_map_addr,
> unsigned long attr)
>  {
> @@ -846,7 +850,9 @@ bool dsp_map(int handle,
> .proc_handle = proc_handle,
> .mpu_addr = mpu_addr,
> .size = size,
> +#if DSP_API >= 3
> .req_addr = req_addr,
> +#endif
> .ret_map_addr = ret_map_addr,
> .attr = attr,
> };
> 
> But then if we are breaking the API already, wouldn't it make 
> sense to use the DMA direction too? (probably on the 'attr' field)
> 
> That's why it's a good idea to discuss API breakage, and not 
> do it willi-nillii. Otherwise we would have #if DSP_API >= 4, 
> and so on.
> 
> But it's a bit pointless to be discussing about this at this 
> point while people are still struggling to get this working 
> and don't know which branch to use.
> 
> Look, you sent patches that broke the bridge (even after 
> manually applying all the dependency patches), since Omar 
> wasn't there as gatekeeper and Greg immediately merge them we 
> now have a bridge that is further broken. And now you want to 
> break it even more arguing that you want to force people to 
> use the new API, but how do you expect people to migrate to 
> this new API if they can't even run this?
> 
> Besides, if you want to break API you should at least mention 
> that clearly in the patch.

Ok lets leave this patch for a moment to send along with all
Depreacted stuff and api changes.

> 
> >> > > > > I think this change should be delayed, preferably
> >> after we have
> >> > > > > a working tidspbridge.
> >> > > >
> >> > > > The issue you were seeing must be fixed with patch 2/8, and
> >> > > Having all
> >> > > > the dependencies tidspbridge has to be working Pr

Re: [Question] which type of DMA taken by musb of beagle-xM(DM3730)?

[Ming Lei]

Hello,

2010/10/27 Anand Gadiyar :
> On 10/27/2010 10:55 AM, Ming Lei wrote:
>>
>> 2010/10/27 Ming Lei:
>>>
>>> Hi Gadiyar,
>>>
>>> Thanks for your reply.
>>>
>>> 2010/10/27 Gadiyar, Anand:

 On Wed, Oct 27, 2010 at 5:54 AM, Ming Lei  wrote:
>
> I want to know which type of DMA is taken by musb of DM3730,
> INVENTRA_DMA, TI_CPPI_DMA or others?

 Inventra DMA. An updated version compared to the OMAP34xx/35xx.

 - No major change to the programming model
 - The simultaneous TX-RX DMA hang bug is gone with this one.
>>>
>>> I find one issue about the dma transfer if Inventra DMA is used, seems
>>> always 2 bytes less than required length, is it caused by unaligned
>>> destination address?
>>>
>>> See the log captured in g_ether context:
>>>
>
> Ouch, yes. I'd forgotten about this one. I think I did post out patches for
> this. But I've moved to other activities and didn't follow up. I'll dig them
> up and  post in a bit.
>
> The issue is that, by design, the last 2 bits of DMA_ADDR are masked by the
> DMA engine; so we need DMA_ADDR to be aligned to a 32-bit boundary.
>
> In gadget mode, g_ether is one driver that's badly affected - there were
> some patches posted which improved g_ether somewhat. In host mode,
> USB-networking cases were most affected. MUSB has two options:
>
> - dma_channel_program can reject transfers to unaligned DMA addresses, so
> that the backup PIO mode can take over (a quick fix - I'll post this one
> again)
>
> - MUSB can bounce the transfer buffer to another buffer which is properly
> aligned
>
> Any other ideas?

Another question, musb_read_fifo and musb_write_fifo need to be fixed to
use 32bit operation only alike am35x?

thanks,
-- 
Lei Ming
--
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

RE: [PATCH v4 0/9] OMAP3: Adding Smartreflex and Voltage driver support

[Gopinath, Thara]

>>-Original Message-
>>From: Menon, Nishanth
>>Sent: Wednesday, October 27, 2010 10:51 PM
>>To: Gopinath, Thara
>>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; khil...@deeprootsystems.com;
>>Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand
>>Subject: Re: [PATCH v4 0/9] OMAP3: Adding Smartreflex and Voltage driver
>>support
>>
>>Gopinath, Thara had written, on 10/27/2010 11:10 AM, the following:
>>> This patch series introduces smartreflex and voltage driver support
>>> for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage
>>> control for real-time voltage adjustments.
>>[..]
>>thanks for the revamped set

You are most welcome!!

>>>
>>> This patch series is based against lo-master with the following additional
>>> patches applied.
>>> https://patchwork.kernel.org/patch/266911/
>>> https://patchwork.kernel.org/patch/266921/
>>> https://patchwork.kernel.org/patch/266931/
>>> https://patchwork.kernel.org/patch/183712/
>>> https://patchwork.kernel.org/patch/285872/
>>>
>>> The entire series with the dependencies are available at
>>> http://dev.omapzoom.org/?p=thara/omap-dvfs.git;a=summary
>>> head: thara-pm-sr
>>>
>>> This patch series has been tested on OMAP3430 SDP with omap2plus_defconfig
>>> with the following menuconfig options enabled.
>>> System type -> TI OMAP Implementations -> Smartreflex Support
>>> System type -> TI OMAP Implementations ->
>>> Class 3 mode of Smartreflex Implementation
>>>
>>Thanks for hosting the branch, Looking at:

Again glad tat u liked it:-)

>>http://dev.omapzoom.org/?p=thara/omap-dvfs.git;a=shortlog;h=refs/heads/thara-
>>pm-sr
>>I am guessing DVFS is missing in this branch? Is it possible to give it
>>a test drive?

Yes.. This is exactly what I am trying to do. Will keep you updated.

>>
>>Also curious should:
>>"OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code should probably be
>>" dropped with "OMAP3: PM: Register TWL4030 pmic info with the voltage" ?

Hmm.. Last time I suggested moving the contents of this patch to twl-core.c
Nobody seemed to much keen. Hence I retained the plat-omap/opp-twl-tpl.c file.
In fact "OMAP3: PM: Register TWL4030 pmic info with the voltage" registers the
params from plat-omap/opp-twl-tpl.c. But if we have a consensus I will just 
drop this patch and have the pmic params passed from twl-core.c.

>>
>>[...]
>>
>>my 2cents: If that tree were organized based on branches which depend on
>>each other it will be easier to identify the dependencies :)
>>probably:
>>kernel.org (now that l-o is merged - potential 2.6.37-rc1)
>>  |- clock patches  -\
>>  |- DVFS series-|
>>  |- OMAP OPP series |
>> |-merged-based -
>>   |-voltage layer & SR series perhaps
>>  |- twl optimization
>>  |- board changes
>>  *** final code ***
>>Just 2 cents to make it easier for folks who are not in PM mostly to see
>>how everything falls together in place..

I agree. But then I need some five patches on top of potential 2.6.37-rc1,
which are not present in any branch. Are you asking me to generate separate 
branches for all these patches?

Regards
Thara
--
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

RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.

[Gopinath, Thara]

>>-Original Message-
>>From: Varadarajan, Charulatha
>>Sent: Thursday, October 28, 2010 11:09 AM
>>To: Gopinath, Thara; linux-omap@vger.kernel.org
>>Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
>>Vishwanath; Sawant, Anand; Gopinath, Thara
>>Subject: RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
>>
>>
>>Thara,
>>
>>> -Original Message-
>>> From: linux-omap-ow...@vger.kernel.org
>>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara Gopinath
>>> Sent: Wednesday, October 27, 2010 9:41 PM
>>> To: linux-omap@vger.kernel.org
>>> Cc: p...@pwsan.com; khil...@deeprootsystems.com; 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_/smartreflex/autocomp
>>> To disable smartreflex autocompensation feature
>>> echo 0 > /debug/voltage/vdd_/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 
>>> ---
>>>  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
>>>
>>
>><>
>>
>>> +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.
>>
>>> +   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.

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;
>>> +   }
>>
>><>
>>
>>-V Charulatha
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of 

RE: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.

[Gopinath, Thara]

>>-Original Message-
>>From: Varadarajan, Charulatha
>>Sent: Thursday, October 28, 2010 11:09 AM
>>To: Gopinath, Thara; linux-omap@vger.kernel.org
>>Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
>>Vishwanath; Sawant, Anand
>>Subject: RE: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
>>
>>Thara,
>>
>>> -Original Message-
>>> From: linux-omap-ow...@vger.kernel.org
>>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
>>> Sent: Wednesday, October 27, 2010 9:41 PM
>>> To: linux-omap@vger.kernel.org
>>> Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
>>> Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
>>> Subject: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
>>>
>>> This patch adds support for device registration of various
>>> smartreflex module present in the system. This patch introduces
>>> the platform data for smartreflex devices which include
>>> the efused and test n-target vaules, module enable/disable
>>> pointers and a parameter to indicate whether smartreflex
>>> autocompensation needs to be enabled on init or not.
>>> Currently auocompensation is enabled on init by default
>>> for OMAP3430 ES3.1 chip.
>>>
>>> Signed-off-by: Thara Gopinath 
>>> ---
>>>  arch/arm/mach-omap2/Makefile|2 +-
>>>  arch/arm/mach-omap2/sr_device.c |  177
>>> +++
>>>  2 files changed, 178 insertions(+), 1 deletions(-)
>>>  create mode 100644 arch/arm/mach-omap2/sr_device.c
>>>
>>
>><>
>>
>>> +
>>> +static int sr_dev_init(struct omap_hwmod *oh, void *user)
>>
>>Since *user is unused, you may rename it to *unused

Ok will do.

>>
>>> +{
>>> +   struct omap_sr_data *sr_data;
>>> +   struct omap_sr_dev_data *sr_dev_data;
>>> +   struct omap_device *od;
>>> +   char *name = "smartreflex";
>>> +   static int i;
>>> +
>>> +   sr_data = kzalloc(sizeof(struct omap_sr_data), GFP_KERNEL);
>>> +   if (!sr_data) {
>>> +   pr_err("%s: Unable to allocate memory for %s
>>> sr_data.Error!\n",
>>> +   __func__, oh->name);
>>> +   return -ENOMEM;
>>> +   }
>>> +
>>> +   sr_dev_data = (struct omap_sr_dev_data *)oh->dev_attr;
>>> +   if (unlikely(!sr_dev_data)) {
>>> +   pr_err("%s: dev atrribute is NULL\n", __func__);
>>> +   goto exit;
>>> +   }
>>> +
>>> +   /*
>>> +* OMAP3430 ES3.1 chips by default come with Efuse burnt
>>> +* with parameters required for full functionality of
>>> +* smartreflex AVS feature like ntarget values , sennenable
>>> +* and senpenable. So enable the SR AVS feature during boot up
>>> +* itself if it is a OMAP3430 ES3.1 chip.
>>> +*/
>>> +   sr_data->enable_on_init = false;
>>> +   if (cpu_is_omap343x())
>>> +   if (omap_rev() == OMAP3430_REV_ES3_1)
>>> +   sr_data->enable_on_init = true;
>>> +
>>> +   sr_data->voltdm =
>>> omap_voltage_domain_lookup(sr_dev_data->vdd_name);
>>> +   if (IS_ERR(sr_data->voltdm)) {
>>> +   pr_err("%s: Unable to get voltage domain
>>> pointer for VDD %s\n",
>>> +   __func__, sr_dev_data->vdd_name);
>>> +   goto exit;
>>> +   }
>>> +
>>> +   sr_dev_data->volts_supported = omap_voltage_get_volttable(
>>> +   sr_data->voltdm, &sr_dev_data->volt_data);
>>> +   if (!sr_dev_data->volts_supported) {
>>> +   pr_warning("%s: No Voltage table registerd fo VDD%d."
>>> +   "Something really wrong\n\n", __func__, i + 1);
>>> +   goto exit;
>>> +   }
>>> +
>>> +   sr_set_nvalues(sr_dev_data, sr_data);
>>> +
>>> +   od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
>>> +  omap_sr_latency,
>>> +  ARRAY_SIZE(omap_sr_latency), 0);
>>
>>Patch 4 should come before patch 3 in the series. Otherwise, this
>>would fail during a git-bisect.

Why?? All patches individually compile and boot.

>>
>>> +   if (IS_ERR(od))
>>> +   pr_warning("%s: Could not build omap_device for
>>> %s: %s.\n\n",
>>> +   __func__, name, oh->name);
>>
>>Return error.
>>
>>> +exit:
>>> +   i++;
>>> +   kfree(sr_data);
>>> +   return 0;
>>> +}
>>> +
>>> +static int __init omap_devinit_smartreflex(void)
>>> +{
>>> +   return omap_hwmod_for_each_by_class("smartreflex",
>>> sr_dev_init, NULL);
>>> +}
>>> +device_initcall(omap_devinit_smartreflex);
>>> --
>>> 1.7.0.4
>>>
>>> --
>>> 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
>>>
--
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

[PATCH 2/2] OMAP: DSS2: Add Seiko 70WVW1TZ3 display panel

[Enric Balletbo i Serra]

From: Enric Balletbo i Serra 

Add new Seiko 70WVW1TZ3, a LCD 7.0inch WVGA (800x480) display
type with 24-bit RGB interface and Touch-Panel

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/video/omap2/displays/Kconfig   |7 +
 drivers/video/omap2/displays/Makefile  |1 +
 .../video/omap2/displays/panel-seiko-70wvw1tz3.c   |  157 
 3 files changed, 165 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-seiko-70wvw1tz3.c

diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index c3aa478..d8e580b 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -51,4 +51,11 @@ config PANEL_POWERTIP_PH480272T
select BACKLIGHT_CLASS_DEVICE
 help
   LCD Panel used in IGEP boards.
+
+config PANEL_SEIKO_70WVW1TZ3
+   tristate "Seiko 70WVW1TZ3 LCD Panel"
+   depends on OMAP2_DSS
+   select BACKLIGHT_CLASS_DEVICE
+help
+  7.0 inch LCD Panel used in IGEP boards.
 endmenu
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index 3967dbc..75e888e 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
 obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
 obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
 obj-$(CONFIG_PANEL_POWERTIP_PH480272T) += panel-powertip-ph480272t.o
+obj-$(CONFIG_PANEL_SEIKO_70WVW1TZ3) += panel-seiko-70wvw1tz3.o
diff --git a/drivers/video/omap2/displays/panel-seiko-70wvw1tz3.c 
b/drivers/video/omap2/displays/panel-seiko-70wvw1tz3.c
new file mode 100644
index 000..0083d54
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-seiko-70wvw1tz3.c
@@ -0,0 +1,157 @@
+/*
+ * LCD panel driver for Seiko 70wvw1tz3Z3
+ *
+ * Copyright (C) 2010, ISEE 2007 SL
+ * Author: Enric Balletbo i Serra 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static struct omap_video_timings s70wvw1tz3_timings = {
+   .x_res = 800,
+   .y_res = 480,
+   .pixel_clock= 33000,
+   .hsw= 128,
+   .hfp= 10,
+   .hbp= 10,
+   .vsw= 2,
+   .vfp= 4,
+   .vbp= 11,
+};
+
+static int s70wvw1tz3_panel_power_on(struct omap_dss_device *dssdev)
+{
+   int r;
+
+   r = omapdss_dpi_display_enable(dssdev);
+   if (r)
+   goto err0;
+
+   /* wait couple of vsyncs until enabling the LCD */
+   msleep(50);
+
+   if (dssdev->platform_enable) {
+   r = dssdev->platform_enable(dssdev);
+   if (r)
+   goto err1;
+   }
+
+   return 0;
+err1:
+   omapdss_dpi_display_disable(dssdev);
+err0:
+   return r;
+}
+
+static void s70wvw1tz3_panel_power_off(struct omap_dss_device *dssdev)
+{
+   if (dssdev->platform_disable)
+   dssdev->platform_disable(dssdev);
+
+   /* wait at least 5 vsyncs after disabling the LCD */
+   msleep(100);
+
+   omapdss_dpi_display_disable(dssdev);
+}
+
+static int s70wvw1tz3_panel_probe(struct omap_dss_device *dssdev)
+{
+   dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+   OMAP_DSS_LCD_IHS;
+
+   dssdev->panel.acb = 0x0;
+   dssdev->panel.timings = s70wvw1tz3_timings;
+
+   return 0;
+}
+
+static void s70wvw1tz3_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int s70wvw1tz3_panel_enable(struct omap_dss_device *dssdev)
+{
+   int r = 0;
+
+   r = s70wvw1tz3_panel_power_on(dssdev);
+   if (r)
+   return r;
+
+   dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+   return 0;
+}
+
+static void s70wvw1tz3_panel_disable(struct omap_dss_device *dssdev)
+{
+   s70wvw1tz3_panel_power_off(dssdev);
+
+   dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+}
+
+static int s70wvw1tz3_panel_suspend(struct omap_dss_device *dssdev)
+{
+   s70wvw1tz3_panel_power_off(dssdev);
+   dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED;
+
+   return 0;
+}
+
+static int s70wvw1tz3_panel_resume(struct omap_dss_device *dssdev)
+{
+   int r = 0;
+
+   r = s70wvw1tz3_panel_power_on(dssdev);
+   if (r)
+   return r;
+
+   dssdev->state = OMAP_

[PATCH 0/2] OMAP: DSS2: Add new display panel

[Enric Balletbo i Serra]

Hi,

Next patches adds support for the two new LCD panel display used
on IGEP boards.

 Powertip PH480272T LCD 4.3inch (480x242) display
 Seiko 70WVW1TZ3 LCD 7.0inch WVGA (800x480) display

Please, consider adding in next merge window.

Cheers,

Enric Balletbo i Serra (2):
  OMAP: DSS2: Add Powertip PH480272T display panel
  OMAP: DSS2: Add Seiko 70WVW1TZ3 display panel

 drivers/video/omap2/displays/Kconfig   |   14 ++
 drivers/video/omap2/displays/Makefile  |2 +
 .../omap2/displays/panel-powertip-ph480272t.c  |  155 +++
 .../video/omap2/displays/panel-seiko-70wvw1tz3.c   |  157 
 4 files changed, 328 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-powertip-ph480272t.c
 create mode 100644 drivers/video/omap2/displays/panel-seiko-70wvw1tz3.c

--
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

[PATCH 1/2] OMAP: DSS2: Add Powertip PH480272T display panel

[Enric Balletbo i Serra]

From: Enric Balletbo i Serra 

Add new Powertip PH480242T panel, a LCD 4.3inch (480x242) display
type with 24-bit RGB interface.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/video/omap2/displays/Kconfig   |7 +
 drivers/video/omap2/displays/Makefile  |1 +
 .../omap2/displays/panel-powertip-ph480272t.c  |  155 
 3 files changed, 163 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-powertip-ph480272t.c

diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index 12327bb..c3aa478 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -44,4 +44,11 @@ config PANEL_ACX565AKM
select BACKLIGHT_CLASS_DEVICE
help
  This is the LCD panel used on Nokia N900
+
+config PANEL_POWERTIP_PH480272T
+   tristate "Powertip PH480272T LCD Panel"
+   depends on OMAP2_DSS
+   select BACKLIGHT_CLASS_DEVICE
+help
+  LCD Panel used in IGEP boards.
 endmenu
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index aa38609..3967dbc 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
 obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
 obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
 obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
+obj-$(CONFIG_PANEL_POWERTIP_PH480272T) += panel-powertip-ph480272t.o
diff --git a/drivers/video/omap2/displays/panel-powertip-ph480272t.c 
b/drivers/video/omap2/displays/panel-powertip-ph480272t.c
new file mode 100644
index 000..d303180
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-powertip-ph480272t.c
@@ -0,0 +1,155 @@
+/*
+ * LCD panel driver for Powertip PH480272T
+ *
+ * Copyright (C) 2010, ISEE 2007 SL
+ * Author: Enric Balletbo i Serra 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static struct omap_video_timings ph480272t_timings = {
+   .x_res  = 480,
+   .y_res  = 272,
+   .pixel_clock= 9000,
+   .hsw= 40,
+   .hfp= 2,
+   .hbp= 2,
+   .vsw= 10,
+   .vfp= 2,
+   .vbp= 2,
+};
+
+static int ph480272t_power_on(struct omap_dss_device *dssdev)
+{
+   int r;
+
+   r = omapdss_dpi_display_enable(dssdev);
+   if (r)
+   goto err0;
+
+   /* wait couple of vsyncs until enabling the LCD */
+   msleep(50);
+
+   if (dssdev->platform_enable) {
+   r = dssdev->platform_enable(dssdev);
+   if (r)
+   goto err1;
+   }
+
+   return 0;
+err1:
+   omapdss_dpi_display_disable(dssdev);
+err0:
+   return r;
+}
+
+static void ph480272t_power_off(struct omap_dss_device *dssdev)
+{
+   if (dssdev->platform_disable)
+   dssdev->platform_disable(dssdev);
+
+   /* wait at least 5 vsyncs after disabling the LCD */
+   msleep(100);
+
+   omapdss_dpi_display_disable(dssdev);
+}
+
+static int ph480272t_probe(struct omap_dss_device *dssdev)
+{
+
+   dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+   OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IEO;
+
+   dssdev->panel.acb = 0x0;
+   dssdev->panel.timings = ph480272t_timings;
+
+   return 0;
+}
+
+static void ph480272t_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int ph480272t_enable(struct omap_dss_device *dssdev)
+{
+   int r = 0;
+
+   r = ph480272t_power_on(dssdev);
+   if (r)
+   return r;
+
+   dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+   return 0;
+}
+
+static void ph480272t_disable(struct omap_dss_device *dssdev)
+{
+   ph480272t_power_off(dssdev);
+
+   dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+}
+
+static int ph480272t_suspend(struct omap_dss_device *dssdev)
+{
+   ph480272t_power_off(dssdev);
+   dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED;
+   return 0;
+}
+
+static int ph480272t_resume(struct omap_dss_device *dssdev)
+{
+   int r = 0;
+
+   r = ph480272t_power_on(dssdev);
+   if (r)
+   return r;
+
+   dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+   return 0;
+}
+
+static struct omap_dss_driver p

RE: [Patch v3] OMAP: AM3517/05: Add craneboard support

[Premi, Sanjeev]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
> srin...@mistralsolutions.com
> Sent: Thursday, October 28, 2010 6:59 PM
> To: linux-omap@vger.kernel.org
> Cc: Kridner, Jason; t...@atomide.com; 
> khil...@deeprootsystems.com; Menon, Nishanth; 
> nagen...@mistralsolutions.com; ume...@mistralsolutions.com; Srinath
> Subject: [Patch v3] OMAP: AM3517/05: Add craneboard support
> 

[snip]

> +MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")

Compared against AM3715, I see these missing:
.phys_io= 0x4800,
.io_pg_offst= ((0xd800) >> 18) & 0xfffc,

Are these not required?

> + .boot_params= 0x8100,
> + .map_io = omap3_map_io,
> + .reserve= omap_reserve,
  
Check for mix of space & tabs here.

~sanjeev

> + .init_irq   = am3517_crane_init_irq,
> + .init_machine   = am3517_crane_init,
> + .timer  = &omap_timer,
> +MACHINE_END
> diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
> b/arch/arm/plat-omap/include/plat/uncompress.h
> index 9036e37..229fbf2 100644
> --- a/arch/arm/plat-omap/include/plat/uncompress.h
> +++ b/arch/arm/plat-omap/include/plat/uncompress.h
> @@ -145,6 +145,7 @@ static inline void 
> __arch_decomp_setup(unsigned long arch_id)
>   /* omap3 based boards using UART3 */
>   DEBUG_LL_OMAP3(3, cm_t35);
>   DEBUG_LL_OMAP3(3, cm_t3517);
> + DEBUG_LL_OMAP3(3, craneboard);
>   DEBUG_LL_OMAP3(3, igep0020);
>   DEBUG_LL_OMAP3(3, igep0030);
>   DEBUG_LL_OMAP3(3, nokia_rx51);
> -- 
> 1.7.1.226.g770c5
> 
> --
> 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
> --
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

RE: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc

[Ghorai, Sukumar]

Tony,

> -Original Message-
> From: Ghorai, Sukumar
> Sent: Wednesday, September 29, 2010 12:08 PM
> To: 'Tony Lindgren'
> Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org
> Subject: RE: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc
> 
> 
[..snip..]

> > > diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
> > omap2/board-3430sdp.c
> > > index 67b95b5..549cd62 100644
> > > --- a/arch/arm/mach-omap2/board-3430sdp.c
> > > +++ b/arch/arm/mach-omap2/board-3430sdp.c
> > > @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void)
> > >   omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
> > >   omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
> > >   omap_init_irq();
> > > + gpmc_init();
> > >   omap_gpio_init();
> > >  }
> > ...
> >
> > You can avoid adding gpmc_init() by making it a subsys_initcall().
> > Just make sure you return early from it with if (!cpu_class_is_omap2()).
> [Ghorai] will do
> >
[Ghorai] I was trying this and no success, as nand_init() get called before  
subsys_initcall(gpmc_init);

126 MACHINE_START(OMAP_ZOOM3, "OMAP Zoom3 board") 
..
130 .init_irq   = omap_zoom_init_irq,
131 .init_machine   = omap_zoom_init,
..

Step-(n):
kernel_init() -> customize_machine() 
 -> omap_zoom_init() -> gpmc_nand_init() -> which call gpmc
functions, that's crashing, as gpmc is not initialized.

Step-(n+1):
Followed by subsys_initcall(gpmc_init)

So I will incorporate the other input and will re-submit.
[..snip..]
--
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

[Patch v3] OMAP: AM3517/05: Add craneboard support

[srinath]

From: Srinath 

Craneboard is a hardware development platform based on the
Sitara AM3517 ARM Cortex - A8 microprocessor device. This is a
low cost reference design.

This patch adds basic board file. Detailed support will follow in
subsequent patches.

  [1] http://www.ti.com/sitara
  [2] http://www.ti.com/arm
  [3] 
http://tiexpressdsp.com/index.php?title=Applications_Processors_Crossreference
  [4] http://marc.info/?l=linux-omap&m=125615009412281&w=2
  [5] http://www.mistralsolutions.com/products/craneboard.php

History and comments:
http://marc.info/?l=linux-omap&w=2&r=1&s=craneboard&q=b

Signed-off-by: Srinath 
---
 arch/arm/mach-omap2/Kconfig  |5 ++
 arch/arm/mach-omap2/Makefile |2 +
 arch/arm/mach-omap2/board-am3517crane.c  |   69 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 77 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-am3517crane.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..3688515 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -174,6 +174,11 @@ config MACH_OMAP3517EVM
default y
select OMAP_PACKAGE_CBB
 
+config MACH_CRANEBOARD
+   bool "AM3517/05 CRANE board"
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+
 config MACH_OMAP3_PANDORA
bool "OMAP3 Pandora"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7352412..f885037 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -170,6 +170,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA)  += 
board-omap4panda.o \
 
 obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
 
+obj-$(CONFIG_MACH_CRANEBOARD)  += board-am3517crane.o
+
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
   hsmmc.o
 # Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am3517crane.c 
b/arch/arm/mach-omap2/board-am3517crane.c
new file mode 100644
index 000..4b209c4
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -0,0 +1,69 @@
+/*
+ * Support for AM3517/05 Craneboard
+ * http://www.mistralsolutions.com/products/craneboard.php
+ *
+ * Copyright (C) 2010 Mistral Solutions Pvt Ltd. 
+ * Author: R.Srinath 
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as  published by the
+ * Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "mux.h"
+
+/* Board initialization */
+static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
+};
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+   { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux  NULL
+#endif
+
+static void __init am3517_crane_init_irq(void)
+{
+   omap_board_config = am3517_crane_config;
+   omap_board_config_size = ARRAY_SIZE(am3517_crane_config);
+
+   omap2_init_common_hw(NULL, NULL);
+   omap_init_irq();
+   omap_gpio_init();
+}
+
+static void __init am3517_crane_init(void)
+{
+   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+   omap_serial_init();
+}
+
+MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")
+   .boot_params= 0x8100,
+   .map_io = omap3_map_io,
+   .reserve= omap_reserve,
+   .init_irq   = am3517_crane_init_irq,
+   .init_machine   = am3517_crane_init,
+   .timer  = &omap_timer,
+MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 9036e37..229fbf2 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -145,6 +145,7 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* omap3 based boards using UART3 */
DEBUG_LL_OMAP3(3, cm_t35);
DEBUG_LL_OMAP3(3, cm_t3517);
+   DEBUG_LL_OMAP3(3, craneboard);
DEBUG_LL_OMAP3(3, igep0020);
DEBUG_LL_OMAP3(3, igep0030);
DEBUG_LL_OMAP3(3, nokia_rx51);
-- 
1.7.1.226.g770c5

--
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

[PATCH 2/3] PERF(kernel): Cleanup power events

[Thomas Renninger]

Recent changes:
  - Enable EVENT_POWER_TRACING_DEPRECATED by default

New power trace events:
power:cpu_idle
power:cpu_frequency
power:machine_suspend


C-state/idle accounting events:
  power:power_start
  power:power_end
are replaced with:
  power:cpu_idle

and
  power:power_frequency
is replaced with:
  power:cpu_frequency

power:machine_suspend
is newly introduced.
Jean Pihet has a patch integrated into the generic layer
(kernel/power/suspend.c) which will make use of it.

the type= field got removed from both, it was never
used and the type is differed by the event type itself.

perf timechart
userspace tool gets adjusted in a separate patch.

Signed-off-by: Thomas Renninger 
Signed-off-by: Arjan van de Ven 
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet 
CC: Arjan van de Ven 
CC: Ingo Molnar 
CC: r...@sisk.pl

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 57d1868..155d975 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -374,6 +374,7 @@ void default_idle(void)
 {
if (hlt_use_halt()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_cpu_idle(1, smp_processor_id());
current_thread_info()->status &= ~TS_POLLING;
/*
 * TS_POLLING-cleared state must be visible before we
@@ -444,6 +445,7 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
 void mwait_idle_with_hints(unsigned long ax, unsigned long cx)
 {
trace_power_start(POWER_CSTATE, (ax>>4)+1, smp_processor_id());
+   trace_cpu_idle((ax>>4)+1, smp_processor_id());
if (!need_resched()) {
if (cpu_has(¤t_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)¤t_thread_info()->flags);
@@ -460,6 +462,7 @@ static void mwait_idle(void)
 {
if (!need_resched()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_cpu_idle(1, smp_processor_id());
if (cpu_has(¤t_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)¤t_thread_info()->flags);
 
@@ -481,10 +484,12 @@ static void mwait_idle(void)
 static void poll_idle(void)
 {
trace_power_start(POWER_CSTATE, 0, smp_processor_id());
+   trace_cpu_idle(0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
-   trace_power_end(0);
+   trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
 }
 
 /*
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 96586c3..4b9befa 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -113,8 +113,8 @@ void cpu_idle(void)
stop_critical_timings();
pm_idle();
start_critical_timings();
-
trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3d9ea53..28153a9 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -142,6 +142,8 @@ void cpu_idle(void)
start_critical_timings();
 
trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT,
+  smp_processor_id());
 
/* In many cases the interrupt that ended idle
   has already called exit_idle. But some idle
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 199dcb9..ed4919e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -355,6 +355,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs 
*freqs, unsigned int state)
dprintk("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
(unsigned long)freqs->cpu);
trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
+   trace_cpu_frequency(freqs->new, freqs->cpu);
srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_POSTCHANGE, freqs);
if (likely(policy) && likely(policy->cpu == freqs->cpu))
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index a507108..08d5f05 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -107,6 +107,7 @@ static void cpuidle_idle_call(void)
if (cpuidle_curr_governor->reflect)
cpuidle_curr_governor->reflect(dev);
trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
 }
 
 /**
diff --git a/drivers/idle/intel_idle.c b/

Re: [linux-pm] [PATCH 2/3] PERF(kernel): Cleanup power events

[Rafael J. Wysocki]

On Thursday, October 28, 2010, Rafael J. Wysocki wrote:
> On Thursday, October 28, 2010, Thomas Renninger wrote:
> > Recent changes:
> >   - Enable EVENT_POWER_TRACING_DEPRECATED by default
> > 
> > New power trace events:
> > power:cpu_idle
> > power:cpu_frequency
> > power:machine_suspend
> > 
> > 
> > C-state/idle accounting events:
> >   power:power_start
> >   power:power_end
> > are replaced with:
> >   power:cpu_idle
> > 
> > and
> >   power:power_frequency
> > is replaced with:
> >   power:cpu_frequency
> > 
> > power:machine_suspend
> > is newly introduced, a first implementation
> > comes from the ARM side, but it's easy to add these events
> > in X86 as well if needed.
> 
> Can you please check that changelog, please?

Sorry s/check/modify/

In fact, there won't be any ARM implementation, because it's going to be
added at the core level.

> I've asked you for that already once.

Thanks,
Rafael
--
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

Re: [PATCH 2/3] PERF(kernel): Cleanup power events

[Rafael J. Wysocki]

On Thursday, October 28, 2010, Thomas Renninger wrote:
> Recent changes:
>   - Enable EVENT_POWER_TRACING_DEPRECATED by default
> 
> New power trace events:
> power:cpu_idle
> power:cpu_frequency
> power:machine_suspend
> 
> 
> C-state/idle accounting events:
>   power:power_start
>   power:power_end
> are replaced with:
>   power:cpu_idle
> 
> and
>   power:power_frequency
> is replaced with:
>   power:cpu_frequency
> 
> power:machine_suspend
> is newly introduced, a first implementation
> comes from the ARM side, but it's easy to add these events
> in X86 as well if needed.

Can you please check that changelog, please?

I've asked you for that already once.

Thanks,
Rafael
--
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

Re: [PATCH 3/3] PERF(userspace): Adjust perf timechart to the new power events

[Thomas Renninger]

On Thursday 28 October 2010 11:02:59 Thomas Renninger wrote:
> Recent changes:
>- Adjust state/cpuid to u32 as done in the kernel
> 
Argh, I forgot a guilt refresh...
Below final :) patch also fixes a bug that got introduced
in 2.6.36 already. Will also send a version for stable
inclusion.

Thomas


PERF(userspace): Adjust perf timechart to the new power events

Recent changes:
   - Adjust state/cpuid to u32 as done in the kernel

The transition was rather smooth, only part I had to fiddle
some time was the check whether a tracepoint/event is
supported by the running kernel.

builtin-timechart must only pass -e power:xy events which
are supported by the running kernel.
For this I added the tiny helper function:
int is_valid_tracepoint(const char *event_string)
to parse-events.[hc]
which could be more generic as an interface and support
hardware/software/... events, not only tracepoints, but someone
else could extend that if needed...

Signed-off-by: Thomas Renninger 
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet 
CC: Arjan van de Ven 
CC: Ingo Molnar 
CC: r...@sisk.pl

diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 9bcc38f..299e488 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -32,6 +32,10 @@
 #include "util/session.h"
 #include "util/svghelper.h"
 
+#define SUPPORT_OLD_POWER_EVENTS 1
+#define PWR_EVENT_EXIT -1
+
+
 static charconst *input_name = "perf.data";
 static charconst *output_name = "output.svg";
 
@@ -298,12 +302,21 @@ struct trace_entry {
int lock_depth;
 };
 
-struct power_entry {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+static int use_old_power_events;
+struct power_entry_old {
struct trace_entry te;
u64 type;
u64 value;
u64 cpu_id;
 };
+#endif
+
+struct power_processor_entry {
+   struct trace_entry te;
+   u32 state;
+   u32 cpu_id;
+};
 
 #define TASK_COMM_LEN 16
 struct wakeup_entry {
@@ -489,29 +502,48 @@ static int process_sample_event(event_t *event, struct 
perf_session *session)
te = (void *)data.raw_data;
if (session->sample_type & PERF_SAMPLE_RAW && data.raw_size > 0) {
char *event_str;
-   struct power_entry *pe;
-
-   pe = (void *)te;
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+   struct power_entry_old *peo;
+   peo = (void *)te;
+#endif
 
event_str = perf_header__find_event(te->type);
 
if (!event_str)
return 0;
 
-   if (strcmp(event_str, "power:power_start") == 0)
-   c_state_start(pe->cpu_id, data.time, pe->value);
-
-   if (strcmp(event_str, "power:power_end") == 0)
-   c_state_end(pe->cpu_id, data.time);
+   if (strcmp(event_str, "power:cpu_idle") == 0) {
+   struct power_processor_entry *ppe = (void *)te;
+   if (ppe->state == (u32)PWR_EVENT_EXIT)
+   c_state_end(ppe->cpu_id, data.time);
+   else
+   c_state_start(ppe->cpu_id, data.time,
+ ppe->state);
+   }
 
-   if (strcmp(event_str, "power:power_frequency") == 0)
-   p_state_change(pe->cpu_id, data.time, pe->value);
+   else if (strcmp(event_str, "power:cpu_frequency") == 0) {
+   struct power_processor_entry *ppe = (void *)te;
+   p_state_change(ppe->cpu_id, data.time, ppe->state);
+   }
 
-   if (strcmp(event_str, "sched:sched_wakeup") == 0)
+   else if (strcmp(event_str, "sched:sched_wakeup") == 0)
sched_wakeup(data.cpu, data.time, data.pid, te);
 
-   if (strcmp(event_str, "sched:sched_switch") == 0)
+   else if (strcmp(event_str, "sched:sched_switch") == 0)
sched_switch(data.cpu, data.time, te);
+
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+   if (use_old_power_events) {
+   if (strcmp(event_str, "power:power_start") == 0)
+   c_state_start(peo->cpu_id, data.time, 
peo->value);
+
+   else if (strcmp(event_str, "power:power_end") == 0)
+   c_state_end(data.cpu, data.time);
+
+   else if (strcmp(event_str, "power:power_frequency") == 
0)
+   p_state_change(peo->cpu_id, data.time, 
peo->value);
+   }
+#endif
}
return 0;
 }
@@ -968,7 +1000,8 @@ static const char * const timechart_usage[] = {
NULL
 };
 
-static const char *record_args[] = {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+static const char *re

[PATCH 2/3] PERF(kernel): Cleanup power events

[Thomas Renninger]

Recent changes:
  - Enable EVENT_POWER_TRACING_DEPRECATED by default

New power trace events:
power:cpu_idle
power:cpu_frequency
power:machine_suspend


C-state/idle accounting events:
  power:power_start
  power:power_end
are replaced with:
  power:cpu_idle

and
  power:power_frequency
is replaced with:
  power:cpu_frequency

power:machine_suspend
is newly introduced, a first implementation
comes from the ARM side, but it's easy to add these events
in X86 as well if needed.

the type= field got removed from both, it was never
used and the type is differed by the event type itself.

perf timechart
userspace tool gets adjusted in a separate patch.

Signed-off-by: Thomas Renninger 
Signed-off-by: Arjan van de Ven 
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet 
CC: Arjan van de Ven 
CC: Ingo Molnar 
CC: r...@sisk.pl
---
 arch/x86/kernel/process.c|7 +++-
 arch/x86/kernel/process_32.c |2 +-
 arch/x86/kernel/process_64.c |2 +
 drivers/cpufreq/cpufreq.c|1 +
 drivers/cpuidle/cpuidle.c|1 +
 drivers/idle/intel_idle.c|1 +
 include/trace/events/power.h |   87 +-
 kernel/trace/Kconfig |   15 +++
 kernel/trace/power-traces.c  |3 +
 9 files changed, 116 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 57d1868..155d975 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -374,6 +374,7 @@ void default_idle(void)
 {
if (hlt_use_halt()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_cpu_idle(1, smp_processor_id());
current_thread_info()->status &= ~TS_POLLING;
/*
 * TS_POLLING-cleared state must be visible before we
@@ -444,6 +445,7 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
 void mwait_idle_with_hints(unsigned long ax, unsigned long cx)
 {
trace_power_start(POWER_CSTATE, (ax>>4)+1, smp_processor_id());
+   trace_cpu_idle((ax>>4)+1, smp_processor_id());
if (!need_resched()) {
if (cpu_has(¤t_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)¤t_thread_info()->flags);
@@ -460,6 +462,7 @@ static void mwait_idle(void)
 {
if (!need_resched()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_cpu_idle(1, smp_processor_id());
if (cpu_has(¤t_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)¤t_thread_info()->flags);
 
@@ -481,10 +484,12 @@ static void mwait_idle(void)
 static void poll_idle(void)
 {
trace_power_start(POWER_CSTATE, 0, smp_processor_id());
+   trace_cpu_idle(0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
-   trace_power_end(0);
+   trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
 }
 
 /*
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 96586c3..4b9befa 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -113,8 +113,8 @@ void cpu_idle(void)
stop_critical_timings();
pm_idle();
start_critical_timings();
-
trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3d9ea53..28153a9 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -142,6 +142,8 @@ void cpu_idle(void)
start_critical_timings();
 
trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT,
+  smp_processor_id());
 
/* In many cases the interrupt that ended idle
   has already called exit_idle. But some idle
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 199dcb9..ed4919e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -355,6 +355,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, 
unsigned int state)
dprintk("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
(unsigned long)freqs->cpu);
trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
+   trace_cpu_frequency(freqs->new, freqs->cpu);
srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_POSTCHANGE, freqs);
if (likely(policy) && likely(policy->cpu == freqs->cpu))
diff --git a/

[PATCH 3/3] PERF(userspace): Adjust perf timechart to the new power events

[Thomas Renninger]

Recent changes:
   - Adjust state/cpuid to u32 as done in the kernel

The transition was rather smooth, only part I had to fiddle
some time was the check whether a tracepoint/event is
supported by the running kernel.

builtin-timechart must only pass -e power:xy events which
are supported by the running kernel.
For this I added the tiny helper function:
int is_valid_tracepoint(const char *event_string)
to parse-events.[hc]
which could be more generic as an interface and support
hardware/software/... events, not only tracepoints, but someone
else could extend that if needed...

Signed-off-by: Thomas Renninger 
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet 
CC: Arjan van de Ven 
CC: Ingo Molnar 
CC: r...@sisk.pl
---
 tools/perf/builtin-timechart.c |   91 ---
 tools/perf/util/parse-events.c |   41 ++
 tools/perf/util/parse-events.h |1 +
 3 files changed, 116 insertions(+), 17 deletions(-)

diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 9bcc38f..1d15228 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -32,6 +32,10 @@
 #include "util/session.h"
 #include "util/svghelper.h"
 
+#define SUPPORT_OLD_POWER_EVENTS 1
+#define PWR_EVENT_EXIT -1
+
+
 static charconst *input_name = "perf.data";
 static charconst *output_name = "output.svg";
 
@@ -298,12 +302,21 @@ struct trace_entry {
int lock_depth;
 };
 
-struct power_entry {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+static int use_old_power_events;
+struct power_entry_old {
struct trace_entry te;
u64 type;
u64 value;
u64 cpu_id;
 };
+#endif
+
+struct power_processor_entry {
+   struct trace_entry te;
+   u32 state;
+   u32 cpu_id;
+};
 
 #define TASK_COMM_LEN 16
 struct wakeup_entry {
@@ -489,29 +502,48 @@ static int process_sample_event(event_t *event, struct 
perf_session *session)
te = (void *)data.raw_data;
if (session->sample_type & PERF_SAMPLE_RAW && data.raw_size > 0) {
char *event_str;
-   struct power_entry *pe;
-
-   pe = (void *)te;
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+   struct power_entry_old *peo;
+   peo = (void *)te;
+#endif
 
event_str = perf_header__find_event(te->type);
 
if (!event_str)
return 0;
 
-   if (strcmp(event_str, "power:power_start") == 0)
-   c_state_start(pe->cpu_id, data.time, pe->value);
-
-   if (strcmp(event_str, "power:power_end") == 0)
-   c_state_end(pe->cpu_id, data.time);
+   if (strcmp(event_str, "power:cpu_idle") == 0) {
+   struct power_processor_entry *ppe = (void *)te;
+   if (ppe->state == (u32)PWR_EVENT_EXIT)
+   c_state_end(ppe->cpu_id, data.time);
+   else
+   c_state_start(ppe->cpu_id, data.time,
+ ppe->state);
+   }
 
-   if (strcmp(event_str, "power:power_frequency") == 0)
-   p_state_change(pe->cpu_id, data.time, pe->value);
+   else if (strcmp(event_str, "power:cpu_frequency") == 0) {
+   struct power_processor_entry *ppe = (void *)te;
+   p_state_change(ppe->cpu_id, data.time, ppe->state);
+   }
 
-   if (strcmp(event_str, "sched:sched_wakeup") == 0)
+   else if (strcmp(event_str, "sched:sched_wakeup") == 0)
sched_wakeup(data.cpu, data.time, data.pid, te);
 
-   if (strcmp(event_str, "sched:sched_switch") == 0)
+   else if (strcmp(event_str, "sched:sched_switch") == 0)
sched_switch(data.cpu, data.time, te);
+
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+   if (use_old_power_events) {
+   if (strcmp(event_str, "power:power_start") == 0)
+   c_state_start(peo->cpu_id, data.time, 
peo->value);
+
+   else if (strcmp(event_str, "power:power_end") == 0)
+   c_state_end(peo->cpu_id, data.time);
+
+   else if (strcmp(event_str, "power:power_frequency") == 
0)
+   p_state_change(peo->cpu_id, data.time, 
peo->value);
+   }
+#endif
}
return 0;
 }
@@ -968,7 +1000,8 @@ static const char * const timechart_usage[] = {
NULL
 };
 
-static const char *record_args[] = {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+static const char *record_old_args[] = {
"record",
"-a",
"-R",
@@ -980,16 +1013,40 @@ static const char *record_args[] = {
"-e",

[PATCH 1/3] PERF: Do not export power_frequency, but power_start event

[Thomas Renninger]

power_frequency moved to drivers/cpufreq/cpufreq.c which has
to be compiled in, no need to export it.

intel_idle can a be module though...

Signed-off-by: Thomas Renninger 
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet 
CC: Arjan van de Ven 
CC: Ingo Molnar 
CC: r...@sisk.pl
---
 drivers/idle/intel_idle.c   |2 --
 kernel/trace/power-traces.c |2 +-
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index c37ef64..21ac077 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -201,9 +201,7 @@ static int intel_idle(struct cpuidle_device *dev, struct 
cpuidle_state *state)
kt_before = ktime_get_real();
 
stop_critical_timings();
-#ifndef MODULE
trace_power_start(POWER_CSTATE, (eax >> 4) + 1, cpu);
-#endif
if (!need_resched()) {
 
__monitor((void *)¤t_thread_info()->flags, 0, 0);
diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
index a22582a..0e0497d 100644
--- a/kernel/trace/power-traces.c
+++ b/kernel/trace/power-traces.c
@@ -13,5 +13,5 @@
 #define CREATE_TRACE_POINTS
 #include 
 
-EXPORT_TRACEPOINT_SYMBOL_GPL(power_frequency);
+EXPORT_TRACEPOINT_SYMBOL_GPL(power_start);
 
-- 
1.6.3

--
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

Cleanup and enhance power trace events

[Thomas Renninger]

Tested with:
acpi_idle and intel_idle as cpuidle drivers.
also tested perf timechart userspace tool without the new interface
and it still works fine with the new kernel changes.

There are quite some issues with the balance of cpu_idle
enter/leave a sleep state, but this was the case already.
perf timechart handles double "leave idle" events gracefully (should
still get fixed up at some time).

The first patch makes intel_idle cpuidle driver tracable, even
if compiled as a module.

Ingo: Can you please push these into an approprate git tree/branch.

Thanks,

Thomas


--
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