RE: [PATCH] OMAP PM: Optimize cpufreq transition latency
Mike, > -Original Message- > From: Turquette, Mike [mailto:mturque...@ti.com] > Sent: Wednesday, December 01, 2010 1:20 AM > To: Vishwanath BS > Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org > Subject: Re: [PATCH] OMAP PM: Optimize cpufreq transition latency > > On Thu, Nov 25, 2010 at 7:38 AM, Vishwanath BS > wrote: > > Currently cpufreq transition latency value does not really reflect the > actual > > OMAP OPP transition delay. This patch has the actual latency value. > > I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 > for worstcase(MPU and Core together) and found that in none of these > platforms, transiton value > > goes beyong 10ms. Added a buffer of 20ms to avoid too frequent > ondemand timer > > expiry. > > With this change, performance of ondemand governor is improved > when tested > > using cpufreqbench tool. Without this patch, cpufreq-bench reported > ondemand > > performance as 40% of performance governor, and with this patch it's > around 70% > > (using below procedure). > > > > cpufreq-bench: > > http://lwn.net/Articles/339862/ > > http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq- > bench/ > > > > Command used for performance testing: > > cpufreq-bench -l 5 -s 10 -x 5 -y 10 -g ondemand - > r 5 -n 5 -v > > > > Signed-off-by: Vishwanath BS > > --- > > arch/arm/plat-omap/cpu-omap.c | 4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > mode change 100644 => 100755 arch/arm/plat-omap/cpu-omap.c > > > > diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat- > omap/cpu-omap.c > > old mode 100644 > > new mode 100755 > > index c47faf8..d3fc423 > > --- a/arch/arm/plat-omap/cpu-omap.c > > +++ b/arch/arm/plat-omap/cpu-omap.c > > @@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct > cpufreq_policy *policy) > > policy->max = policy->cpuinfo.max_freq; > > policy->cur = omap_getspeed(0); > > > > - /* FIXME: what's the actual transition time? */ > > - policy->cpuinfo.transition_latency = 300 * 1000; > > + /* Program the actual transition time for worstcase */ > > + policy->cpuinfo.transition_latency = 30 * 1000; > > Vishwa, > > This is a frequent periodic timer. Does a smaller value have any > affect on CPUidle wakeups? I do not think so since this is a deferrable timer which should not interrupt CPUIdle. Vishwa > > Thanks, > Mike > > > return 0; > > } > > -- > > 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
RE: [PATCH v2 13/14] OMAP3: Add voltage dependency table for VDD1.
Thara,
> -Original Message-
> From: Gopinath, Thara
> Sent: Friday, October 29, 2010 9:08 PM
> To: linux-omap@vger.kernel.org
> Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
> Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
> Subject: [PATCH v2 13/14] OMAP3: Add voltage dependency table for
> VDD1.
>
> In OMAP3, for perfomrance reasons when VDD1 is at voltage above
> 1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
> patch introduce this cross VDD dependency for OMAP3 VDD1.
>
> Signed-off-by: Thara Gopinath
> ---
> arch/arm/mach-omap2/voltage.c | 19 +++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
> omap2/voltage.c
> index 6f85f75..241fac5 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -350,6 +350,23 @@ static struct omap_volt_data
> omap44xx_vdd_core_volt_data[] = {
> {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain =
> 0x16},
> };
>
> +/* OMAP 3430 MPU Core VDD dependency table */
> +static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
> + {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
> + {.main_vdd_volt = 1075000, .dep_vdd_volt = 105},
> + {.main_vdd_volt = 120, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 127, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 135, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 0, .dep_vdd_volt = 0},
> +};
> +
> +static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
> + {
> + .name = "core",
> + .dep_table = omap34xx_vdd1_vdd2_data,
> + },
> +};
Dependency table for 3630 is missing. Pls add the same.
Also voltage values for 3630 does not match those on OPP table. Pls align
them.
Vishwa
> +
> /* By default VPFORCEUPDATE is the chosen method of voltage scaling
> */
> static bool voltscale_vpforceupdate = true;
>
> @@ -574,6 +591,8 @@ static void __init
> omap3_vdd_data_configure(struct omap_vdd_info *vdd)
> vdd->volt_data = omap34xx_vdd1_volt_data;
> vdd->volt_data_count =
>
> ARRAY_SIZE(omap34xx_vdd1_volt_data);
> + vdd->dep_vdd_info = omap34xx_vdd1_dep_info;
> + vdd->nr_dep_vdd =
> ARRAY_SIZE(omap34xx_vdd1_dep_info);
> }
>
> vdd->vp_reg.tranxdone_status =
> OMAP3430_VP1_TRANXDONE_ST_MASK;
> --
> 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
RE: [PATCH v2 13/14] OMAP3: Add voltage dependency table for VDD1.
Thara,
> -Original Message-
> From: Gopinath, Thara
> Sent: Friday, October 29, 2010 9:08 PM
> To: linux-omap@vger.kernel.org
> Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
> Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
> Subject: [PATCH v2 13/14] OMAP3: Add voltage dependency table for
> VDD1.
>
> In OMAP3, for perfomrance reasons when VDD1 is at voltage above
> 1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
> patch introduce this cross VDD dependency for OMAP3 VDD1.
>
> Signed-off-by: Thara Gopinath
> ---
> arch/arm/mach-omap2/voltage.c | 19 +++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
> omap2/voltage.c
> index 6f85f75..241fac5 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -350,6 +350,23 @@ static struct omap_volt_data
> omap44xx_vdd_core_volt_data[] = {
> {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain =
> 0x16},
> };
>
> +/* OMAP 3430 MPU Core VDD dependency table */
> +static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
> + {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
> + {.main_vdd_volt = 1075000, .dep_vdd_volt = 105},
> + {.main_vdd_volt = 120, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 127, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 135, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 0, .dep_vdd_volt = 0},
> +};
> +
> +static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
> + {
> + .name = "core",
> + .dep_table = omap34xx_vdd1_vdd2_data,
> + },
> +};
Dependency table for 3630 is missing. Pls add the same.
Also voltage values for 3630 does not match those on OPP table. Pls align
them.
Vishwa
> +
> /* By default VPFORCEUPDATE is the chosen method of voltage scaling
> */
> static bool voltscale_vpforceupdate = true;
>
> @@ -574,6 +591,8 @@ static void __init
> omap3_vdd_data_configure(struct omap_vdd_info *vdd)
> vdd->volt_data = omap34xx_vdd1_volt_data;
> vdd->volt_data_count =
>
> ARRAY_SIZE(omap34xx_vdd1_volt_data);
> + vdd->dep_vdd_info = omap34xx_vdd1_dep_info;
> + vdd->nr_dep_vdd =
> ARRAY_SIZE(omap34xx_vdd1_dep_info);
> }
>
> vdd->vp_reg.tranxdone_status =
> OMAP3430_VP1_TRANXDONE_ST_MASK;
> --
> 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
RE: [PATCH v2 13/14] OMAP3: Add voltage dependency table for VDD1.
Thara,
> -Original Message-
> From: Gopinath, Thara
> Sent: Friday, October 29, 2010 9:08 PM
> To: linux-omap@vger.kernel.org
> Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
> Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
> Subject: [PATCH v2 13/14] OMAP3: Add voltage dependency table for
> VDD1.
>
> In OMAP3, for perfomrance reasons when VDD1 is at voltage above
> 1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
> patch introduce this cross VDD dependency for OMAP3 VDD1.
>
> Signed-off-by: Thara Gopinath
> ---
> arch/arm/mach-omap2/voltage.c | 19 +++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
> omap2/voltage.c
> index 6f85f75..241fac5 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -350,6 +350,23 @@ static struct omap_volt_data
> omap44xx_vdd_core_volt_data[] = {
> {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain =
> 0x16},
> };
>
> +/* OMAP 3430 MPU Core VDD dependency table */
> +static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
> + {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
> + {.main_vdd_volt = 1075000, .dep_vdd_volt = 105},
> + {.main_vdd_volt = 120, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 127, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 135, .dep_vdd_volt = 115},
> + {.main_vdd_volt = 0, .dep_vdd_volt = 0},
> +};
> +
> +static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
> + {
> + .name = "core",
> + .dep_table = omap34xx_vdd1_vdd2_data,
> + },
> +};
Dependency table for 3630 is missing. Pls add the same.
Also voltage values for 3630 does not match those on OPP table. Pls align
them.
Vishwa
> +
> /* By default VPFORCEUPDATE is the chosen method of voltage scaling
> */
> static bool voltscale_vpforceupdate = true;
>
> @@ -574,6 +591,8 @@ static void __init
> omap3_vdd_data_configure(struct omap_vdd_info *vdd)
> vdd->volt_data = omap34xx_vdd1_volt_data;
> vdd->volt_data_count =
>
> ARRAY_SIZE(omap34xx_vdd1_volt_data);
> + vdd->dep_vdd_info = omap34xx_vdd1_dep_info;
> + vdd->nr_dep_vdd =
> ARRAY_SIZE(omap34xx_vdd1_dep_info);
> }
>
> vdd->vp_reg.tranxdone_status =
> OMAP3430_VP1_TRANXDONE_ST_MASK;
> --
> 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
RE: [PATCHv2]OMAP PM:MPU/DMA Latency constraints
Kevin/Paul,
Do you have any comments on this patch?
Regards
Vishwa
> -Original Message-
> From: Vishwanath BS [mailto:vishwanath...@ti.com]
> Sent: Tuesday, November 16, 2010 2:50 PM
> To: linux-omap@vger.kernel.org
> Cc: Vishwanath BS; Kevin Hilman; Paul Walmsley
> Subject: [PATCHv2]OMAP PM:MPU/DMA Latency constraints
>
> The previous implementation of OMAP interrupt/DMA latency constraints
> were implemented using SRF which is obsolete now. This patch has
> implemented the same using PM QOS infeastructure. As part of this, API
> signature has been changed to take pm qos handle instead of dev pointer
> since PM QOS infrastructure takes pm_qos handle to distingush different
> latency requests.So each driver is expected to have it's own pm_qos
> handle.
> However it's an opaque handle from driver's point of view as drivers
just
> need to define a handle and this handle gets initialized automatically
> when
> they make the first mpu/dma latency request.
>
> Cc: Kevin Hilman
> Cc: Paul Walmsley
>
> Signed-off-by: Vishwanath BS
>
> The changes are rebased to latest kevin's origin/pm branch and tested
> on OMAP ZOOM3.
> ---
> V2: aligned the implementation with latest PM QOS APIs
> addressed comments from Kevin Hilman
> (https://patchwork.kernel.org/patch/113855/)
>
> V1: Initial Patch
>
> arch/arm/plat-omap/Kconfig|3 +
> arch/arm/plat-omap/Makefile |1 +
> arch/arm/plat-omap/i2c.c |3 +-
> arch/arm/plat-omap/include/plat/omap-pm.h | 13 +-
> arch/arm/plat-omap/omap-pm-noop.c | 20 +-
> arch/arm/plat-omap/omap-pm.c | 316
> +
> 6 files changed, 341 insertions(+), 15 deletions(-)
> create mode 100755 arch/arm/plat-omap/omap-pm.c
>
> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> index 92c5bb7..4ff485e 100644
> --- a/arch/arm/plat-omap/Kconfig
> +++ b/arch/arm/plat-omap/Kconfig
> @@ -184,6 +184,9 @@ config OMAP_PM_NONE
> config OMAP_PM_NOOP
> bool "No-op/debug PM layer"
>
> +config OMAP_PM
> + depends on PM
> + bool "OMAP PM layer implementation"
> endchoice
>
> endmenu
> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
> index 3f0a2bb..545a6a1 100644
> --- a/arch/arm/plat-omap/Makefile
> +++ b/arch/arm/plat-omap/Makefile
> @@ -38,3 +38,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
> obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
>
> obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
> +obj-$(CONFIG_OMAP_PM) += omap-pm.o
> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
> index a5bff9c..eb9a7cb 100644
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -114,7 +114,8 @@ static inline int omap1_i2c_add_bus(int bus_id)
> */
> static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device
> *dev, long t)
> {
> - omap_pm_set_max_mpu_wakeup_lat(dev, t);
> + static struct pm_qos_request_list *qos_handle;
> + omap_pm_set_max_mpu_wakeup_lat(&qos_handle, t);
> }
>
> static struct omap_device_pm_latency omap_i2c_latency[] = {
> diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
> b/arch/arm/plat-omap/include/plat/omap-pm.h
> index c5b533d..6425e82
> --- a/arch/arm/plat-omap/include/plat/omap-pm.h
> +++ b/arch/arm/plat-omap/include/plat/omap-pm.h
> @@ -20,6 +20,7 @@
>
> #include "powerdomain.h"
> #include
> +#include
>
> /*
> * agent_id values for use with omap_pm_set_min_bus_tput():
> @@ -75,7 +76,8 @@ void omap_pm_if_exit(void);
>
> /**
> * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU
> wakeup latency
> - * @dev: struct device * requesting the constraint
> + * @qos_request: handle for the constraint. The pointer should be
> + * initialized to NULL
> * @t: maximum MPU wakeup latency in microseconds
> *
> * Request that the maximum interrupt latency for the MPU to be no
> @@ -107,7 +109,8 @@ void omap_pm_if_exit(void);
> * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
> * is not satisfiable, or 0 upon success.
> */
> -int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
> +int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list
> **qos_request,
> + long t);
>
>
> /**
> @@ -174,7 +177,8 @@ int omap_pm_set_max_dev_wakeup_lat(struct
> device *req_dev, struct device *dev,
>
> /**
> * omap_pm_set_max_sdma_lat - set the maximum system DMA
> transfer start latency
> - * @dev: struct device *
> + * @qos_request: handle for the constraint. The pointer should be
> + * initialized to NULL
> * @t: maximum DMA transfer start latency in microseconds
> *
> * Request that the maximum system DMA transfer start latency for this
> @@ -199,7 +203,8 @@ int omap_pm_set_max_dev_wakeup_lat(struct
> device *req_dev, struct device *dev,
> * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
> * is not satisfiable, or 0 upon success.
> */
> -int omap_pm_set_max_sdma_lat(struct
RE: [PATCH/RFC 2/2] OMAP: PM: implement context loss count APIs
Kevin,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Friday, December 10, 2010 5:39 AM
> To: linux-omap@vger.kernel.org
> Cc: Paul Walmsely
> Subject: [PATCH/RFC 2/2] OMAP: PM: implement context loss count APIs
>
> Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API
> by
> creating similar APIs at the omap_device and omap_hwmod levels. The
> omap_hwmod level call is the layer with access to the powerdomain
> core, so it is the place where the powerdomain is queried to get the
> context loss count.
>
> NOTE: only works for devices which have been converted to use
> omap_device/omap_hwmod.
>
> Longer term, we could possibly remove this API from the OMAP PM layer,
> and instead directly use the omap_device level API.
>
> Cc: Paul Walmsley
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 18
> ++
> arch/arm/plat-omap/include/plat/omap_device.h |1 +
> arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
> arch/arm/plat-omap/omap-pm-noop.c | 17 +-
> ---
> arch/arm/plat-omap/omap_device.c | 20
>
> 5 files changed, 49 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
> omap2/omap_hwmod.c
> index 81c1097..0ec9c70 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2220,3 +2220,21 @@ ohsps_unlock:
>
> return ret;
> }
> +
> +/**
> + * omap_hwmod_get_context_loss_count - get lost context count
> + * @oh: struct omap_hwmod *
> + *
> + * Query the powerdomain of of @oh to get the context loss
> + * count for this device.
> + */
> +int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
> +{
> + struct powerdomain *pwrdm;
> +
> + pwrdm = omap_hwmod_get_pwrdm(oh);
> + if (!pwrdm)
> + return -ENODEV;
> +
> + return pwrdm_get_context_loss_count(pwrdm);
> +}
> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
> b/arch/arm/plat-omap/include/plat/omap_device.h
> index 28e2d1a..70d31d0 100644
> --- a/arch/arm/plat-omap/include/plat/omap_device.h
> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> @@ -107,6 +107,7 @@ void __iomem *omap_device_get_rt_va(struct
> omap_device *od);
> int omap_device_align_pm_lat(struct platform_device *pdev,
>u32 new_wakeup_lat_limit);
> struct powerdomain *omap_device_get_pwrdm(struct omap_device
> *od);
> +int omap_device_get_context_loss_count(struct platform_device
> *pdev);
>
> /* Other */
>
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index 62bdb23..5a96ac5 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -568,6 +568,7 @@ int omap_hwmod_for_each_by_class(const char
> *classname,
>void *user);
>
> int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8
> state);
> +int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
>
> /*
> * Chip variant-specific hwmod init routines - XXX should be converted
> diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-
> omap/omap-pm-noop.c
> index 7578366..5a58f97 100644
> --- a/arch/arm/plat-omap/omap-pm-noop.c
> +++ b/arch/arm/plat-omap/omap-pm-noop.c
> @@ -20,9 +20,11 @@
> #include
> #include
> #include
> +#include
>
> /* Interface documentation is in mach/omap-pm.h */
> #include
> +#include
>
> struct omap_opp *dsp_opps;
> struct omap_opp *mpu_opps;
> @@ -288,20 +290,19 @@ unsigned long omap_pm_cpu_get_freq(void)
>
> int omap_pm_get_dev_context_loss_count(struct device *dev)
> {
> + struct platform_device *pdev = to_platform_device(dev);
> + int count;
> +
> if (!dev) {
> WARN_ON(1);
> return -EINVAL;
> };
>
> - pr_debug("OMAP PM: returning context loss count for dev %s\n",
> - dev_name(dev));
> + count = omap_device_get_context_loss_count(pdev);
> + pr_debug("OMAP PM: context loss count for dev %s = %d\n",
> + dev_name(dev), count);
Shouldn't this implementation be part of omap-pm.c where all the OMAP PM
functions are to be implemented? I thought omap-pm-noop.c should have
dummy implementation.
Vishwa
>
> - /*
> - * Map the device to the powerdomain. Return the powerdomain
> - * off counter.
> - */
> -
> - return 0;
> + return count;
> }
>
>
> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
> omap/omap_device.c
> index abe933c..e29c2d6 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -280,6 +280,26 @@ static void _add_optional_clock_alias(struct
> omap_device *od,
> /* Public functions for use by core code */
>
> /**
> + * omap_device_get_context_loss_coun
RE: [PATCH/RFC 2/2] OMAP: PM: implement context loss count APIs
Kevin,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Saturday, December 11, 2010 6:14 AM
> To: Vishwanath Sripathy
> Cc: linux-omap@vger.kernel.org; Paul Walmsely
> Subject: Re: [PATCH/RFC 2/2] OMAP: PM: implement context loss count
> APIs
>
> Vishwanath Sripathy writes:
>
> > Kevin,
> [...]
>
> >> @@ -288,20 +290,19 @@ unsigned long
> omap_pm_cpu_get_freq(void)
> >>
> >> int omap_pm_get_dev_context_loss_count(struct device *dev)
> >> {
> >> + struct platform_device *pdev = to_platform_device(dev);
> >> + int count;
> >> +
> >>if (!dev) {
> >>WARN_ON(1);
> >>return -EINVAL;
> >>};
> >>
> >> - pr_debug("OMAP PM: returning context loss count for dev %s\n",
> >> - dev_name(dev));
> >> + count = omap_device_get_context_loss_count(pdev);
> >> + pr_debug("OMAP PM: context loss count for dev %s = %d\n",
> >> + dev_name(dev), count);
> >
> > Shouldn't this implementation be part of omap-pm.c where all the
> OMAP PM
> > functions are to be implemented?
>
> Where is omap-pm.c?
It's not present and needs to be added. This file is anyway required for
adding device latency constraints as well.
Vishwa
>
> Kevin
--
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 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Nishant,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Friday, December 03, 2010 10:34 PM
> To: linux-omap
> Cc: Eduardo Valentin; Kevin Hilman; Tony Lindgren; Nishanth Menon
> Subject: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if
> < ES1.2
>
> From: Eduardo Valentin
>
> Limitation i583: Self_Refresh Exit issue after OFF mode
>
> Issue:
> When device is waking up from OFF mode, then SDRC state machine
> sends
> inappropriate sequence violating JEDEC standards.
>
> Impact:
> OMAP3630 < ES1.2 is impacted as follows depending on the platform:
> CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable,
> while
> for all other sysclk frequencies, varied levels of instability
> seen based on varied parameters.
> CS1: impacted
>
> This patch takes option #3 as recommended by the Silicon erratum:
> Avoid core power domain transitioning to OFF mode. Power consumption
> impact is expected in this case.
> To do this, we route OFF requests to RET request on the impacted
> revisions
> of silicon.
>
> Cc: Kevin Hilman
> Cc: Tony Lindgren
>
> [...@ti.com: rebased the code to 2.6.37-rc2- short circuit code changed
> a bit]
> Signed-off-by: Nishanth Menon
> Signed-off-by: Eduardo Valentin
> ---
> v3: no functional change in erratum wa implementation, just registration
> of
> erratum is collated to a single cpu detection and version check
> v2: https://patchwork.kernel.org/patch/365262/
> rebased to this patch series instead of depending on hs changes
> fix typo for macro definition
> v1: http://marc.info/?l=linux-omap&m=129013173425266&w=2
> arch/arm/mach-omap2/pm34xx.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
> omap2/pm34xx.c
> index b49e02b..ba3c0d6 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -56,6 +56,7 @@
> #define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
>
> #define RTA_ERRATUM_i608 (1 << 0)
> +#define SDRC_WAKEUP_ERRATUM_i583 (1 << 1)
> static u16 pm34xx_errata;
> #define IS_PM34XX_ERRATUM(id)(pm34xx_errata & (id))
>
> @@ -406,6 +407,17 @@ void omap_sram_idle(void)
> }
>
> /* CORE */
> + /*
> + * Erratum i583: implementation for ES rev < Es1.2 on 3630
> + * We cannot enable OFF mode in a stable form for previous
> + * revisions, transition instead to RET
> + */
> + if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583) &&
> + (core_next_state == PWRDM_POWER_OFF)) {
> + pwrdm_set_next_pwrst(core_pwrdm,
> PWRDM_POWER_RET);
> + core_next_state = PWRDM_POWER_RET;
> + }
Since next_state in pwrst_list (for core) is not updated, this is throwing
up an error "Powerdomain (core_pwrdm) didn't enter target state 0" when
you off mode is enabled for ES1.1 or lesser (in suspend path). It's not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in omap_sram_idle.
However it did not enter the state that was passed by omap3_pm_suspend. Is
this expected behavior?
Vishwa
> +
> if (core_next_state < PWRDM_POWER_ON) {
> omap_uart_prepare_idle(0);
> omap_uart_prepare_idle(1);
> @@ -999,6 +1011,8 @@ static void __init pm_errata_configure(void)
> pm34xx_errata |= RTA_ERRATUM_i608;
> /* Enable the l2 cache toggling in sleep logic */
> enable_omap3630_toggle_l2_on_restore();
> + if (omap_rev() < OMAP3630_REV_ES1_2)
> + pm34xx_errata |= SDRC_WAKEUP_ERRATUM_i583;
> }
> }
>
> --
> 1.6.3.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
--
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/RFC 2/2] OMAP: PM: implement context loss count APIs
Paul,
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Monday, December 13, 2010 4:13 PM
> To: Vishwanath Sripathy
> Cc: Kevin Hilman; linux-omap@vger.kernel.org
> Subject: RE: [PATCH/RFC 2/2] OMAP: PM: implement context loss count
> APIs
>
> Hello Vishwa,
>
> On Fri, 10 Dec 2010, Vishwanath Sripathy wrote:
>
> > > + count = omap_device_get_context_loss_count(pdev);
> > > + pr_debug("OMAP PM: context loss count for dev %s = %d\n",
> > > + dev_name(dev), count);
> > Shouldn't this implementation be part of omap-pm.c where all the
> OMAP PM
> > functions are to be implemented? I thought omap-pm-noop.c should
> have
> > dummy implementation.
>
> In general, yes. But we also want the code in omap-pm-noop.c not to
> cause
> additional breakage. Unlike most of the other functions in this file,
if
> the context loss count function doesn't do something minimally useful,
> then
> the system is going to break badly. You've probably seen this thread:
>
> http://www.mail-archive.com/linux-
> o...@vger.kernel.org/msg40079.html
>
> (By the way, the reason why I think we shouldn't use the approach
> described in
>
> http://www.mail-archive.com/linux-
> o...@vger.kernel.org/msg40101.html
>
> is because I suspect it is going to seriously damage retention idle
> performance. For example, the HSMMC driver resets its entire IP block
in
> its context restore function...)
>
> But to confirm your general point, yes, in general, further functional
> development of the OMAP PM code should take place outside the no-op
> file.
> Hopefully, at some point, we'll be able to drop the no-op file. Once
> there is a useful replacement, we should be able to switch to it as a
> default.
I have no issues with the implementation and I agree. All I am saying is
that why can't this implementation be added in omap-pm.c and compile this
file instead of omap-pm-noop.c when OMAP_PM is enabled. I believe this
function is useful when off mode is enabled which means OMAP_PM is
enabled.
Vishwa
>
>
> - Paul
--
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 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Nishant,
> -Original Message-
> From: Nishanth Menon [mailto:n...@ti.com]
> Sent: Monday, December 13, 2010 7:13 PM
> To: Vishwanath Sripathy
> Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
> Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
> coreoff if < ES1.2
>
> Vishwanath Sripathy had written, on 12/13/2010 07:35 AM, the
> following:
> > Nishant,
> >
> >> -Original Message-
> >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> >> ow...@vger.kernel.org] On Behalf Of Nishanth Menon
> >> Sent: Friday, December 03, 2010 10:34 PM
> >> To: linux-omap
> >> Cc: Eduardo Valentin; Kevin Hilman; Tony Lindgren; Nishanth Menon
> >> Subject: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
> coreoff if
> >> < ES1.2
> >>
> >> From: Eduardo Valentin
> >>
> >> Limitation i583: Self_Refresh Exit issue after OFF mode
> >>
> >> Issue:
> >> When device is waking up from OFF mode, then SDRC state machine
> >> sends
> >> inappropriate sequence violating JEDEC standards.
> >>
> >> Impact:
> >> OMAP3630 < ES1.2 is impacted as follows depending on the
> platform:
> >> CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable,
> >> while
> >>for all other sysclk frequencies, varied levels of instability
> >>seen based on varied parameters.
> >> CS1: impacted
> >>
> >> This patch takes option #3 as recommended by the Silicon erratum:
> >> Avoid core power domain transitioning to OFF mode. Power
> consumption
> >> impact is expected in this case.
> >> To do this, we route OFF requests to RET request on the impacted
> >> revisions
> >> of silicon.
> >>
> >> Cc: Kevin Hilman
> >> Cc: Tony Lindgren
> >>
> >> [...@ti.com: rebased the code to 2.6.37-rc2- short circuit code
> changed
> >> a bit]
> >> Signed-off-by: Nishanth Menon
> >> Signed-off-by: Eduardo Valentin
> >> ---
> >> v3: no functional change in erratum wa implementation, just
> registration
> >> of
> >>erratum is collated to a single cpu detection and version check
> >> v2: https://patchwork.kernel.org/patch/365262/
> >> rebased to this patch series instead of depending on hs changes
> >> fix typo for macro definition
> >> v1: http://marc.info/?l=linux-omap&m=129013173425266&w=2
> >> arch/arm/mach-omap2/pm34xx.c | 14 ++
> >> 1 files changed, 14 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
> >> omap2/pm34xx.c
> >> index b49e02b..ba3c0d6 100644
> >> --- a/arch/arm/mach-omap2/pm34xx.c
> >> +++ b/arch/arm/mach-omap2/pm34xx.c
> >> @@ -56,6 +56,7 @@
> >> #define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
> >>
> >> #define RTA_ERRATUM_i608 (1 << 0)
> >> +#define SDRC_WAKEUP_ERRATUM_i583 (1 << 1)
> >> static u16 pm34xx_errata;
> >> #define IS_PM34XX_ERRATUM(id) (pm34xx_errata & (id))
> >>
> >> @@ -406,6 +407,17 @@ void omap_sram_idle(void)
> >>}
> >>
> >>/* CORE */
> >> + /*
> >> + * Erratum i583: implementation for ES rev < Es1.2 on 3630
> >> + * We cannot enable OFF mode in a stable form for previous
> >> + * revisions, transition instead to RET
> >> + */
> >> + if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583) &&
> >> + (core_next_state == PWRDM_POWER_OFF)) {
> >> + pwrdm_set_next_pwrst(core_pwrdm,
> >> PWRDM_POWER_RET);
> >> + core_next_state = PWRDM_POWER_RET;
> >> + }
> >
> > Since next_state in pwrst_list (for core) is not updated, this is
throwing
> > up an error "Powerdomain (core_pwrdm) didn't enter target state 0"
> when
> > you off mode is enabled for ES1.1 or lesser (in suspend path). It's
not
> > really true that Core has not entered target state. It has entered
> > Retention state which is the actual target state set in
omap_sram_idle.
> > However it did not enter the state that was passed by
> omap3_pm_suspend. Is
> > this expected behavior?
>
> we could go both ways on this - this patch will(as you noticed) indicate
> that the transition failed on transparent(by modifying the the pwrst_list - claim we achieved off,
> while not really hitting off - I personally dont think that is correct.
The point I am making is that you cannot distinguish between genuine off
/retention failure since this message is thrown for both pass and fail.
May be an additional trace message indicating that system entered
retention instead of off (for ES<1.2) will be useful.
Vishwa
>
> --
> Regards,
> Nishanth Menon
--
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 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Nishant, > -Original Message- > From: Nishanth Menon [mailto:n...@ti.com] > Sent: Monday, December 13, 2010 7:35 PM > To: Vishwanath Sripathy > Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren > Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable > coreoff if < ES1.2 > > Vishwanath Sripathy had written, on 12/13/2010 07:54 AM, the > following: > > Nishant, > > > >> -Original Message- > >> From: Nishanth Menon [mailto:n...@ti.com] > >> Sent: Monday, December 13, 2010 7:13 PM > >> To: Vishwanath Sripathy > >> Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren > >> Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable > >> coreoff if < ES1.2 > >> > >> Vishwanath Sripathy had written, on 12/13/2010 07:35 AM, the > >> following: > >>> Nishant, > >>> > >>>> -Original Message- > >>>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > >>>> ow...@vger.kernel.org] On Behalf Of Nishanth Menon > >>>> Sent: Friday, December 03, 2010 10:34 PM > >>>> To: linux-omap > >>>> Cc: Eduardo Valentin; Kevin Hilman; Tony Lindgren; Nishanth > Menon > >>>> Subject: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable > >> coreoff if > >>>> < ES1.2 > >>>> > >>>> From: Eduardo Valentin > >>>> > >>>> Limitation i583: Self_Refresh Exit issue after OFF mode > >>>> > >>>> Issue: > >>>> When device is waking up from OFF mode, then SDRC state > machine > >>>> sends > >>>> inappropriate sequence violating JEDEC standards. > >>>> > >>>> Impact: > >>>> OMAP3630 < ES1.2 is impacted as follows depending on the > >> platform: > >>>> CS0: for 38.4MHz as internal sysclk, DDR content seen to be > stable, > >>>> while > >>>> for all other sysclk frequencies, varied levels of instability > >>>> seen based on varied parameters. > >>>> CS1: impacted > >>>> > >>>> This patch takes option #3 as recommended by the Silicon > erratum: > >>>> Avoid core power domain transitioning to OFF mode. Power > >> consumption > >>>> impact is expected in this case. > >>>> To do this, we route OFF requests to RET request on the impacted > >>>> revisions > >>>> of silicon. > >>>> > >>>> Cc: Kevin Hilman > >>>> Cc: Tony Lindgren > >>>> > >>>> [...@ti.com: rebased the code to 2.6.37-rc2- short circuit code > >> changed > >>>> a bit] > >>>> Signed-off-by: Nishanth Menon > >>>> Signed-off-by: Eduardo Valentin > >>>> --- > >>>> v3: no functional change in erratum wa implementation, just > >> registration > >>>> of > >>>> erratum is collated to a single cpu detection and version > check > >>>> v2: https://patchwork.kernel.org/patch/365262/ > >>>> rebased to this patch series instead of depending on hs > changes > >>>> fix typo for macro definition > >>>> v1: http://marc.info/?l=linux-omap&m=129013173425266&w=2 > >>>> arch/arm/mach-omap2/pm34xx.c | 14 ++ > >>>> 1 files changed, 14 insertions(+), 0 deletions(-) > >>>> > >>>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach- > >>>> omap2/pm34xx.c > >>>> index b49e02b..ba3c0d6 100644 > >>>> --- a/arch/arm/mach-omap2/pm34xx.c > >>>> +++ b/arch/arm/mach-omap2/pm34xx.c > >>>> @@ -56,6 +56,7 @@ > >>>> #define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8 > >>>> > >>>> #define RTA_ERRATUM_i608(1 << 0) > >>>> +#define SDRC_WAKEUP_ERRATUM_i583(1 << 1) > >>>> static u16 pm34xx_errata; > >>>> #define IS_PM34XX_ERRATUM(id) (pm34xx_errata & (id)) > >>>> > >>>> @@ -406,6 +407,17 @@ void omap_sram_idle(void) > >>>> } > >>>> > >>>> /* CORE */ > >>>> +/* > >>>> + * Erratum i583: implementation for ES rev < Es1.2 on > 3630 > >>>> + * We cannot
RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
> -Original Message-
> From: Nishanth Menon [mailto:n...@ti.com]
> Sent: Monday, December 13, 2010 8:14 PM
> To: Vishwanath Sripathy
> Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
> Subject: RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
> coreoff if < ES1.2
>
> > -Original Message-
> > Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the
> following:
> > [...]
> > >>>>>> +if
> (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
> > >> &&
> > >>>>>> +(core_next_state ==
> PWRDM_POWER_OFF))
> > >> {
> > >>>>>> +pwrdm_set_next_pwrst(core_pwrdm,
> > >>>>>> PWRDM_POWER_RET);
> > >>>>>> +core_next_state = PWRDM_POWER_RET;
> > >>>>>> +}
> > >>>>> Since next_state in pwrst_list (for core) is not updated, this
is
> > >>> throwing
> > >>>>> up an error "Powerdomain (core_pwrdm) didn't enter target
> state
> > >> 0"
> > >>>> when
> > >>>>> you off mode is enabled for ES1.1 or lesser (in suspend path).
> It's
> > >>> not
> > >>>>> really true that Core has not entered target state. It has
> entered
> > >>>>> Retention state which is the actual target state set in
> > >>> omap_sram_idle.
> > >>>>> However it did not enter the state that was passed by
> > >>>> omap3_pm_suspend. Is
> > >>>>> this expected behavior?
> > >>>> we could go both ways on this - this patch will(as you noticed)
> > >> indicate
> > >>>> that the transition failed on entirely
> > >>>> transparent(by modifying the the pwrst_list - claim we achieved
> off,
> > >>>> while not really hitting off - I personally dont think that is
> > > correct.
> > >>> The point I am making is that you cannot distinguish between
> genuine
> > >> off
> > >>> /retention failure since this message is thrown for both pass and
> > > fail.
> > >>> May be an additional trace message indicating that system
> entered
> > >>> retention instead of off (for ES<1.2) will be useful.
> > >> hmm... good point there.
> > >> two issues here:
> > >> a) omap3_pm_suspend should probably state which state was
> achieved
> > >> as
> > >> well in the error message (trivial fix).
> > >> b) how do we notify users that it was due to
> > >> SDRC_WAKEUP_ERRATUM_i583
> > >> that core-off was denied. -> do this in omap3_pm_suspend(when
> user
> > >> attempts actual OFF) OR omap3_pm_off_mode_enable(when user
> > >> attempts to
> > >> enable OFF mode)?
> > >>
> > >> Any suggestions to allow the same uImage boot on all silicon +
> allow
> > >> cpu_idle + suspend paths not to spew pr_info messages(aka cant
> add
> > >> prints in sram_idle)?
> > > I vote for denying off mode for Core (for ES<1.2) in
> > > omap3_pm_off_mode_enable and throw up a message saying that
> Core off
> is
> > > not enabled. Then we will not get this failure message in suspend
> path
> > > since pwrst_list will have the right state.
> > Keep in mind - if we disable it in omap3_pm_off_mode_enable - we
> will
> > deny OFF wholesale if I understand the logic right- not just core-off
-
> > I kind of think that is extreme.
>
> I take that back, we could do something like the following instead:
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
> omap2/pm34xx.c
> index ba3c0d6..74842f1 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -933,7 +933,14 @@ void omap3_pm_off_mode_enable(int enable)
>
> list_for_each_entry(pwrst, &pwrst_list, node) {
> pwrst->next_state = state;
> - omap_set_pwrdm_state(pwrst->pwrdm, state);
> + if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
> &&
> + pwrst->pwrdm == core_pwrdm) {
> + omap_set_pwrdm_state(pwrst->pwrdm,
> PWRDM_POWER_RET);
You need to update pwrst->next_state as well.
Otherwise suspend will still throw the same error. I just sent the code in
other email.
Vishwa
> + pr_err("%s: cannot enable Core OFF due to
i583\n",
> + __func__);
> + } else {
> + omap_set_pwrdm_state(pwrst->pwrdm, state);
> + }
> }
> }
>
> Will wait to see if there are additional opinions on this approach -if
> none,
> Will post a v4 for this patch alone.
> Regards,
> Nishanth Menon
--
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] OMAP3: clean up ASM idle code
> -Original Message- > From: jean.pi...@newoldbits.com [mailto:jean.pi...@newoldbits.com] > Sent: Tuesday, December 07, 2010 4:42 PM > To: linux-omap@vger.kernel.org > Cc: Jean Pihet; Vishwanath BS > Subject: [PATCH] OMAP3: clean up ASM idle code > > From: Jean Pihet > > Clean up of the ASM code: > - reorganized the code in logical sections: defines, API >functions, internal functions and variables, > - reworked and simplified the execution paths, for better >readability and to avoid duplication of code, > - added comments on the entry and exit points, > - reworked the existing comments for better readability, > - reworked the code formating, alignment and white spaces, > - added comments for the i443 erratum workarounds, > - changed the hardcoded values in favor of existing macros >from include files, > - clean up of non used symbols. > > Tested on OMAP3EVM and Beagleboard with full RET and OFF modes. > > Heavily reworked from Vishwa's original patch. > > Signed-off-by: Jean Pihet > Cc: Vishwanath BS Tested on ZOOM3 for Retention and OFF in suspend and Idle path. Acked-by: Vishwanath BS > --- > Applies on top of Nishant's latest idle path errata fixes step 2, > cf. http://marc.info/?l=linux-omap&m=129139584919242&w=2 > > arch/arm/mach-omap2/control.h |2 + > arch/arm/mach-omap2/pm.h|1 - > arch/arm/mach-omap2/pm34xx.c|4 +- > arch/arm/mach-omap2/sleep34xx.S | 522 > +-- > 4 files changed, 288 insertions(+), 241 deletions(-) > > diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach- > omap2/control.h > index d7911c5..72efefb 100644 > --- a/arch/arm/mach-omap2/control.h > +++ b/arch/arm/mach-omap2/control.h > @@ -274,6 +274,8 @@ > #define OMAP343X_SCRATCHPAD_ROM > (OMAP343X_CTRL_BASE + 0x860) > #define OMAP343X_SCRATCHPAD (OMAP343X_CTRL_BASE + > 0x910) > #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C > +#define OMAP343X_SCRATCHPAD_REGADDR(reg) > OMAP2_L4_IO_ADDRESS(\ > + OMAP343X_SCRATCHPAD + > reg) > > /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ > #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 > diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h > index aff39d0..e458b2a 100644 > --- a/arch/arm/mach-omap2/pm.h > +++ b/arch/arm/mach-omap2/pm.h > @@ -80,7 +80,6 @@ extern void save_secure_ram_context(u32 *addr); > extern void omap3_save_scratchpad_contents(void); > > extern unsigned int omap24xx_idle_loop_suspend_sz; > -extern unsigned int omap34xx_suspend_sz; > extern unsigned int save_secure_ram_context_sz; > extern unsigned int omap24xx_cpu_suspend_sz; > extern unsigned int omap34xx_cpu_suspend_sz; > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach- > omap2/pm34xx.c > index a37d53d..c93b872 100644 > --- a/arch/arm/mach-omap2/pm34xx.c > +++ b/arch/arm/mach-omap2/pm34xx.c > @@ -135,7 +135,7 @@ static void omap3_core_save_context(void) > > /* >* Force write last pad into memory, as this can fail in some > - * cases according to erratas 1.157, 1.185 > + * cases according to errata 1.157 & 1.185 >*/ > > omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D1 > 4), > OMAP343X_CONTROL_MEM_WKUP + 0x2a0); > @@ -432,7 +432,7 @@ void omap_sram_idle(void) > /* > * On EMU/HS devices ROM code restores a SRDC value > * from scratchpad which has automatic self refresh on timeout > - * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. > + * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443. > * Hence store/restore the SDRC_POWER register here. > */ > if (omap_rev() >= OMAP3430_REV_ES3_0 && > diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach- > omap2/sleep34xx.S > index d2eda01..96a4864 100644 > --- a/arch/arm/mach-omap2/sleep34xx.S > +++ b/arch/arm/mach-omap2/sleep34xx.S > @@ -33,24 +33,27 @@ > #include "sdrc.h" > #include "control.h" > > -#define SDRC_SCRATCHPAD_SEM_V0xfa00291c > - > -#define PM_PREPWSTST_CORE_V > OMAP34XX_PRM_REGADDR(CORE_MOD, \ > - OMAP3430_PM_PREPWSTST) > -#define PM_PREPWSTST_CORE_P 0x48306AE8 > -#define PM_PREPWSTST_MPU_V > OMAP34XX_PRM_REGADDR(MPU_MOD, \ > - OMAP3430_PM_PREPWSTST) > +/* > + * Registers access definitions > + */ > +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc > +#define SDRC_SCRATCHPAD_SEM_V > OMAP343X_SCRATCHPAD_REGADDR\ > + (SDRC_SCRATCHPAD_SEM_OFFS) > +#define PM_PREPWSTST_CORE_P OMAP3430_PRM_BASE + CORE_MOD > +\ > + OMAP3430_PM_PREPWSTST > #define PM_PWSTCTRL_MPU_POMAP3430_PRM_BASE + MPU_MOD > + OMAP2_PM_PWSTCTRL > #define CM_IDLEST1_CORE_V > OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) > #define CM_IDLEST_CKGEN_VOMAP34XX_CM_REGADDR(PLL_MOD, > CM_IDLEST) > #define SRAM_BASE_P 0x4020 > -#define CO
RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Nishant,
> -Original Message-
> From: Nishanth Menon [mailto:n...@ti.com]
> Sent: Monday, December 13, 2010 8:07 PM
> To: Vishwanath Sripathy
> Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
> Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
> coreoff if < ES1.2
>
> Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the
> following:
> [...]
> >>>>>> + if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
> >> &&
> >>>>>> + (core_next_state == PWRDM_POWER_OFF))
> >> {
> >>>>>> + pwrdm_set_next_pwrst(core_pwrdm,
> >>>>>> PWRDM_POWER_RET);
> >>>>>> + core_next_state = PWRDM_POWER_RET;
> >>>>>> + }
> >>>>> Since next_state in pwrst_list (for core) is not updated, this is
> >>> throwing
> >>>>> up an error "Powerdomain (core_pwrdm) didn't enter target
> state
> >> 0"
> >>>> when
> >>>>> you off mode is enabled for ES1.1 or lesser (in suspend path).
> It's
> >>> not
> >>>>> really true that Core has not entered target state. It has entered
> >>>>> Retention state which is the actual target state set in
> >>> omap_sram_idle.
> >>>>> However it did not enter the state that was passed by
> >>>> omap3_pm_suspend. Is
> >>>>> this expected behavior?
> >>>> we could go both ways on this - this patch will(as you noticed)
> >> indicate
> >>>> that the transition failed on >>>> transparent(by modifying the the pwrst_list - claim we achieved
> off,
> >>>> while not really hitting off - I personally dont think that is
> > correct.
> >>> The point I am making is that you cannot distinguish between
> genuine
> >> off
> >>> /retention failure since this message is thrown for both pass and
> > fail.
> >>> May be an additional trace message indicating that system entered
> >>> retention instead of off (for ES<1.2) will be useful.
> >> hmm... good point there.
> >> two issues here:
> >> a) omap3_pm_suspend should probably state which state was
> achieved
> >> as
> >> well in the error message (trivial fix).
> >> b) how do we notify users that it was due to
> >> SDRC_WAKEUP_ERRATUM_i583
> >> that core-off was denied. -> do this in omap3_pm_suspend(when
> user
> >> attempts actual OFF) OR omap3_pm_off_mode_enable(when user
> >> attempts to
> >> enable OFF mode)?
> >>
> >> Any suggestions to allow the same uImage boot on all silicon + allow
> >> cpu_idle + suspend paths not to spew pr_info messages(aka cant
> add
> >> prints in sram_idle)?
> > I vote for denying off mode for Core (for ES<1.2) in
> > omap3_pm_off_mode_enable and throw up a message saying that
> Core off is
> > not enabled. Then we will not get this failure message in suspend path
> > since pwrst_list will have the right state.
> Keep in mind - if we disable it in omap3_pm_off_mode_enable - we will
> deny OFF wholesale if I understand the logic right- not just core-off -
> I kind of think that is extreme.
No, I am not saying that deny idle for all power domains. Deny it only for
Core domain, something like this.
void omap3_pm_off_mode_enable(int enable)
{
struct power_state *pwrst;
u32 state;
if (enable)
state = PWRDM_POWER_OFF;
else
state = PWRDM_POWER_RET;
#ifdef CONFIG_CPU_IDLE
omap3_cpuidle_update_states();
#endif
list_for_each_entry(pwrst, &pwrst_list, node) {
pwrst->next_state = state;
if (strcmp("core_pwrdm", pwrst->pwrdm->name)==0) {
if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
&& state ==PWRDM_POWER_OFF)
pwrst->next_state = PWRDM_POWER_RET;
}
omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
}
}
Vishwa
>
> --
> Regards,
> Nishanth Menon
--
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 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
> -Original Message-
> From: Nishanth Menon [mailto:n...@ti.com]
> Sent: Monday, December 13, 2010 8:23 PM
> To: Vishwanath Sripathy
> Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
> Subject: Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
> coreoff if < ES1.2
>
> Vishwanath Sripathy had written, on 12/13/2010 08:48 AM, the
> following:
> >> -Original Message-
> >> From: Nishanth Menon [mailto:n...@ti.com]
> >> Sent: Monday, December 13, 2010 8:14 PM
> >> To: Vishwanath Sripathy
> >> Cc: linux-omap; Eduardo Valentin; Kevin Hilman; Tony Lindgren
> >> Subject: RE: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable
> >> coreoff if < ES1.2
> >>
> >>> -Original Message-
> >>> Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the
> >> following:
> >>> [...]
> >>>>>>>>> + if
> >> (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
> >>>>> &&
> >>>>>>>>> + (core_next_state ==
> >> PWRDM_POWER_OFF))
> >>>>> {
> >>>>>>>>> + pwrdm_set_next_pwrst(core_pwrdm,
> >>>>>>>>> PWRDM_POWER_RET);
> >>>>>>>>> + core_next_state = PWRDM_POWER_RET;
> >>>>>>>>> + }
> >>>>>>>> Since next_state in pwrst_list (for core) is not updated, this
> > is
> >>>>>> throwing
> >>>>>>>> up an error "Powerdomain (core_pwrdm) didn't enter target
> >> state
> >>>>> 0"
> >>>>>>> when
> >>>>>>>> you off mode is enabled for ES1.1 or lesser (in suspend
> path).
> >> It's
> >>>>>> not
> >>>>>>>> really true that Core has not entered target state. It has
> >> entered
> >>>>>>>> Retention state which is the actual target state set in
> >>>>>> omap_sram_idle.
> >>>>>>>> However it did not enter the state that was passed by
> >>>>>>> omap3_pm_suspend. Is
> >>>>>>>> this expected behavior?
> >>>>>>> we could go both ways on this - this patch will(as you
> noticed)
> >>>>> indicate
> >>>>>>> that the transition failed on >> entirely
> >>>>>>> transparent(by modifying the the pwrst_list - claim we
> achieved
> >> off,
> >>>>>>> while not really hitting off - I personally dont think that is
> >>>> correct.
> >>>>>> The point I am making is that you cannot distinguish between
> >> genuine
> >>>>> off
> >>>>>> /retention failure since this message is thrown for both pass
> and
> >>>> fail.
> >>>>>> May be an additional trace message indicating that system
> >> entered
> >>>>>> retention instead of off (for ES<1.2) will be useful.
> >>>>> hmm... good point there.
> >>>>> two issues here:
> >>>>> a) omap3_pm_suspend should probably state which state was
> >> achieved
> >>>>> as
> >>>>> well in the error message (trivial fix).
> >>>>> b) how do we notify users that it was due to
> >>>>> SDRC_WAKEUP_ERRATUM_i583
> >>>>> that core-off was denied. -> do this in
> omap3_pm_suspend(when
> >> user
> >>>>> attempts actual OFF) OR omap3_pm_off_mode_enable(when
> user
> >>>>> attempts to
> >>>>> enable OFF mode)?
> >>>>>
> >>>>> Any suggestions to allow the same uImage boot on all silicon +
> >> allow
> >>>>> cpu_idle + suspend paths not to spew pr_info messages(aka
> cant
> >> add
> >>>>> prints in sram_idle)?
> >>>> I vote for denying off mode for Core (for ES<1.2) in
> >>>> omap3_pm_off_mode_enable and throw up a message saying
> that
> >> Core off
> >> is
> >>>> not enabled. Then we will not get this failure message in suspend
> >> path
> >>>> since pwrst_list will have the right state.
> >>> Keep in mind - if we disable it in omap3_pm_off_mode_enable - we
> >> will
> >>> deny OFF wholesale if I unders
RE: [PATCH] OMAP3: clean up ASM idle code
Jean,
> -Original Message-
> From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
> Sent: Tuesday, December 14, 2010 2:53 PM
> To: Kevin Hilman; Vishwanath BS
> Cc: linux-omap@vger.kernel.org; Jean Pihet
> Subject: Re: [PATCH] OMAP3: clean up ASM idle code
>
> Kevin,
>
> On Tue, Dec 14, 2010 at 5:12 AM, Kevin Hilman
> wrote:
> > jean.pi...@newoldbits.com writes:
> >
> >> From: Jean Pihet
> >>
> >> Clean up of the ASM code:
> >> - reorganized the code in logical sections: defines, API
> >> á áfunctions, internal functions and variables,
> >> - reworked and simplified the execution paths, for better
> >> á áreadability and to avoid duplication of code,
> >> - added comments on the entry and exit points,
> >> - reworked the existing comments for better readability,
> >> - reworked the code formating, alignment and white spaces,
> >> - added comments for the i443 erratum workarounds,
> >> - changed the hardcoded values in favor of existing macros
> >> á áfrom include files,
> >> - clean up of non used symbols.
> >
> > The 'lock_scratchpad_sem' code is also unused. áIIRC, you removed
> that
> > in an earlier version of the series. áAre you still planning to remove
> > that? maybe in a subsequent patch?
>
> I asked previously about it and the reply was that this code is
> needed: (quoting Vishwa's reply) "This is indeed used during DVFS when
> Core DPLL configuration is changed". Note: the DVFS code is not
> upstreamed yet.
>
> Vishwa, can you confirm?
lock_scratchpad_sem is needed when DVFS feature is supported. If you want
to add this implementation as part of DVFS feature, then also it's fine.
Vishwa
>
> > That being said, pure whitespace changes and unused code removal
> should
> > probably be a separate patch. áIt's a great help to reviewers if
> > functional changes are separated from whitespace changes. áIt's a bit
> > tricky in this series as there's lots of code moving as well, so I'll
> > leave it up to your judgement on how/if to separate these out.
>
> There is no functional change at all. The code has been reorganized
> for better readability.
> I agree the patch is not easy to read but that is the way diff reports
> the changes.
>
> I do not see the point to provide separate patches for code move,
> white space clean-up, alignment fixes etc.
>
> >> Tested on OMAP3EVM and Beagleboard with full RET and OFF modes.
> >
> > In idle? áin suspend? áboth? áwas CPUidle enabled?
> >
> > FWIW, I tested on 3430-ES3.1/n900 with retention idle & suspend and
> off
> > idle & suspend with CPUidle enabled.
> Tested with cpuidle and suspend. I will update the description.
>
> >
> >> Heavily reworked from Vishwa's original patch.
> >
> > Here, it's more customary to ásay "Based on original patch from
> Vishwa"
> > and ensure the original author is CC'd (which you've done.)
> >
> > Other than that, this is a great cleanup, and makes this much more
> > readable. áThanks.
> >
> > Some other minor comments below.
>
> OK thanks for the review. I will post a new version asap.
>
> >
> >> Signed-off-by: Jean Pihet
> >> Cc: Vishwanath BS
> >> ---
> >> Applies on top of Nishant's latest idle path errata fixes step 2,
> >> cf. http://marc.info/?l=linux-omap&m=129139584919242&w=2
> >>
> >
> > [...]
> >
> >> @@ -208,36 +172,153 @@ api_params:
> >> áENTRY(save_secure_ram_context_sz)
> >> á á á .word á . - save_secure_ram_context
> >>
> >> +
> >> +/* ==
> >> + * == Idle entry point ==
> >> + * ==
> >> + */
> >
> > Let's keep C multi-line coding style even for assembly. á Same goes
for
> > several other places below.
> Ok
>
> >
> >> á/*
> >> á * Forces OMAP into idle state
> >> á *
> >> - * omap34xx_suspend() - This bit of code just executes the WFI
> >> - * for normal idles.
> >> + * omap34xx_suspend() - This bit of code saves the CPU context if
> needed
> >> + * and executes the WFI instruction
> >> + *
> >> + * Note: This code get's copied to internal SRAM at boot.
> >> á *
> >> - * Note: This code get's copied to internal SRAM at boot. When the
> OMAP
> >> - * á áwakes up it continues execution at the point it went to sleep.
> >> + * Note: When the OMAP wakes up it continues at different
> execution points,
> >> + * ádepending on the low power mode (non-OFF vs OFF modes),
> >> + * ácf. 'Resume path for xxx mode' comments.
> >> á */
> >> áENTRY(omap34xx_cpu_suspend)
> >> á á á stmfd á sp!, {r0-r12, lr} á á á á á á á @ save registers on
stack
> >> áloop:
> >> á á á /*b á á loop*/ �...@enable to debug by stepping through code
> >
> > While here, let's get rid of these infinite loop hacks for debugging
as
> > anyone debugging this code can add these back as needed.
> áOtherwise,
> > they clutter the code. á There are a few of theses throughout the
> > original code.
> Ok. Agree those are not used at all (even when doing heavy debugging).
>
> > [...]
> >
> >> @@ -250,9 +331,28 @@ loop:
> >> á á á nop
> >> á á á bl wait_sdrc_ok
> >>
> >> - á á ldmfd á sp!, {r0-r12, pc} á á á á á á á
RE: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support
Kevin, > -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Friday, December 17, 2010 7:01 AM > To: Thara Gopinath > Cc: linux-omap@vger.kernel.org; p...@pwsan.com; b-cous...@ti.com; > vishwanath...@ti.com; saw...@ti.com; n...@ti.com > Subject: Re: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage > driver support > > Hi Thara, > > Thara Gopinath writes: > > > This patch series introduces smartreflex and voltage driver support > > for OMAP3430 and OMAP3630. SmartReflex modules do adaptive > voltage > > control for real-time voltage adjustments. > > > [...] > > > This patch series has been tested on OMAP3430 SDP with > omap2plus_defconfig > > with the following menuconfig options enabled. > > Any testing on 3630? I tested this on ZOOM3 and it works fine. Vishwa > > > System type -> TI OMAP Implementations -> Smartreflex Support > > System type -> TI OMAP Implementations -> > > Class 3 mode of Smartreflex Implementation > > > > Major Changes in v5 > > > > - Rebased to k.org 2.6.37-rc3 > > - Rebased to Nishant Menon's latest opp patches > > - Voltage pmic info structure extended to include a > > vast set of PMIC dependent parameters. > > - Smartreflex software n-target values support > > removed from the kernel. Instead n-target > > values are exposed as debugfs entries which can > > be written into by the user if needed. > > - Introduced a new file arch/arm/mach-omap2/omap_twl.c > > for specifying OMAP and TWL related info for > > the voltage layer. > > - Remove default enabling of smartreflex autocompensation > > during boot on OMAP3430 ES3.1 chips. Instead > > an API is provided that can be called from > > board files in case autocompensation needs > > to be enabled during boot up itself. > > - Other review comments on v4 > > > > > > This series is looking good. I have a couple minor comments on specific > patches. > > Also, it needs (hopefully only) one more rebase/repost. > > First, a few things have changed at the PRCM API level that need to be > updated. I have a untested patch (below) that should fix this for you, > that you'll need to split and apply to the OMAP3 and OMAP4 voltage > driver patches. > > To test with those changes, you can rebase onto my pm-core branch, > which > contains not only the PRCM API changes, but also Nishanth's latest OPP > branch, and several other clock, hwmod, PM core changes queued for > 2.6.38 > > Second, please also Cc the linux-arm-kernel mailing list, so if/when we > merge this into linux-omap, it doesn't need a last minute repost. > > Thanks, > > Kevin -- 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/7] OMAP3: remove hardcoded values from the ASM sleep code
> -Original Message- > From: jean.pi...@newoldbits.com [mailto:jean.pi...@newoldbits.com] > Sent: Saturday, December 18, 2010 9:15 PM > To: linux-omap@vger.kernel.org > Cc: khil...@deeprootsystems.com; linux-arm- > ker...@lists.infradead.org; Jean Pihet; Vishwanath BS > Subject: [PATCH 3/7] OMAP3: remove hardcoded values from the ASM > sleep code > > From: Jean Pihet > > Using macros from existing include files for registers addresses. > > Tested on N900 and Beagleboard with full RET and OFF modes, > using cpuidle and suspend. > > Based on original patch from Vishwa. > > Signed-off-by: Jean Pihet > Cc: Vishwanath BS Acked-by: Vishwanath BS > Acked-by: Santosh Shilimkar > Tested-by: Nishanth Menon > --- > arch/arm/mach-omap2/control.h |2 ++ > arch/arm/mach-omap2/sleep34xx.S | 29 > ++--- > 2 files changed, 20 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach- > omap2/control.h > index d7911c5..72efefb 100644 > --- a/arch/arm/mach-omap2/control.h > +++ b/arch/arm/mach-omap2/control.h > @@ -274,6 +274,8 @@ > #define OMAP343X_SCRATCHPAD_ROM > (OMAP343X_CTRL_BASE + 0x860) > #define OMAP343X_SCRATCHPAD (OMAP343X_CTRL_BASE + > 0x910) > #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C > +#define OMAP343X_SCRATCHPAD_REGADDR(reg) > OMAP2_L4_IO_ADDRESS(\ > + OMAP343X_SCRATCHPAD + > reg) > > /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ > #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 > diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach- > omap2/sleep34xx.S > index 406cd2a..8e9f38f 100644 > --- a/arch/arm/mach-omap2/sleep34xx.S > +++ b/arch/arm/mach-omap2/sleep34xx.S > @@ -34,20 +34,27 @@ > #include "sdrc.h" > #include "control.h" > > -#define SDRC_SCRATCHPAD_SEM_V0xfa00291c > - > -#define PM_PREPWSTST_CORE_P 0x48306AE8 > +/* > + * Registers access definitions > + */ > +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc > +#define SDRC_SCRATCHPAD_SEM_V > OMAP343X_SCRATCHPAD_REGADDR\ > + (SDRC_SCRATCHPAD_SEM_OFFS) > +#define PM_PREPWSTST_CORE_P OMAP3430_PRM_BASE + CORE_MOD > +\ > + OMAP3430_PM_PREPWSTST > #define PM_PWSTCTRL_MPU_POMAP3430_PRM_BASE + MPU_MOD > + OMAP2_PM_PWSTCTRL > #define CM_IDLEST1_CORE_V > OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) > #define CM_IDLEST_CKGEN_VOMAP34XX_CM_REGADDR(PLL_MOD, > CM_IDLEST) > -#define SRAM_BASE_P 0x4020 > -#define CONTROL_STAT 0x480022F0 > -#define CONTROL_MEM_RTA_CTRL (OMAP343X_CTRL_BASE\ > - + > OMAP36XX_CONTROL_MEM_RTA_CTRL) > -#define SCRATCHPAD_MEM_OFFS 0x310 /* Move this as correct place is > -* available */ > -#define SCRATCHPAD_BASE_P(OMAP343X_CTRL_BASE + > OMAP343X_CONTROL_MEM_WKUP\ > - + SCRATCHPAD_MEM_OFFS) > +#define SRAM_BASE_P OMAP3_SRAM_PA > +#define CONTROL_STAT OMAP343X_CTRL_BASE + > OMAP343X_CONTROL_STATUS > +#define CONTROL_MEM_RTA_CTRL (OMAP343X_CTRL_BASE +\ > + > OMAP36XX_CONTROL_MEM_RTA_CTRL) > + > +/* Move this as correct place is available */ > +#define SCRATCHPAD_MEM_OFFS 0x310 > +#define SCRATCHPAD_BASE_P(OMAP343X_CTRL_BASE +\ > + OMAP343X_CONTROL_MEM_WKUP +\ > + SCRATCHPAD_MEM_OFFS) > #define SDRC_POWER_V > OMAP34XX_SDRC_REGADDR(SDRC_POWER) > #define SDRC_SYSCONFIG_P (OMAP343X_SDRC_BASE + > SDRC_SYSCONFIG) > #define SDRC_MR_0_P (OMAP343X_SDRC_BASE + > SDRC_MR_0) > -- > 1.7.2.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
RE: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
Paul, Do you intend to merge this patch for 2.6.38? I did not see this in your pull request. Vishwa > -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Tuesday, October 05, 2010 8:48 PM > To: Sripathy, Vishwanath > Cc: linux-omap@vger.kernel.org; Premi, Sanjeev > Subject: Re: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 > for Global SW reset > > On Tue, 5 Oct 2010, Vishwanath BS wrote: > > > This patch adds comments on precatution to be taken if Global Warm > reset is > > used as the means to trigger sysem reset. > > > > Signed-off-by: Vishwanath BS > > Cc: Paul Walmsley > > Thanks, queued for 2.6.38 with Sanjeev's spelling fix. > > > - Paul -- 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: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
Paul, Do you intend to merge this patch for 2.6.38? I did not see this in your pull request. Vishwa > -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Tuesday, October 05, 2010 8:48 PM > To: Sripathy, Vishwanath > Cc: linux-omap@vger.kernel.org; Premi, Sanjeev > Subject: Re: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 > for Global SW reset > > On Tue, 5 Oct 2010, Vishwanath BS wrote: > > > This patch adds comments on precatution to be taken if Global Warm > reset is > > used as the means to trigger sysem reset. > > > > Signed-off-by: Vishwanath BS > > Cc: Paul Walmsley > > Thanks, queued for 2.6.38 with Sanjeev's spelling fix. > > > - Paul -- 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: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
Paul, Pls ignore my other 2 emails. There were some issues in my mailbox. Vishwa > -Original Message- > From: Sripathy, Vishwanath [mailto:vishwanath...@ti.com] > Sent: Wednesday, December 22, 2010 1:58 PM > To: Paul Walmsley > Cc: linux-omap@vger.kernel.org; Premi, Sanjeev > Subject: RE: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 > for Global SW reset > > Paul, > > > -Original Message- > > From: Paul Walmsley [mailto:p...@pwsan.com] > > Sent: Tuesday, October 05, 2010 8:48 PM > > To: Sripathy, Vishwanath > > Cc: linux-omap@vger.kernel.org; Premi, Sanjeev > > Subject: Re: [PATCHv3] OMAP3: SDRC : Add comments on Errata i520 > > for Global SW reset > > > > On Tue, 5 Oct 2010, Vishwanath BS wrote: > > > > > This patch adds comments on precatution to be taken if Global > Warm > > reset is > > > used as the means to trigger sysem reset. > > > > > > Signed-off-by: Vishwanath BS > > > Cc: Paul Walmsley > > > > Thanks, queued for 2.6.38 with Sanjeev's spelling fix. > > Do you intend to merge this patch for 2.6.38? I did not see this in > your pull request. > > Vishwa > > > > > > > - Paul -- 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 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
Benoit,
> -Original Message-
> From: Cousson, Benoit [mailto:b-cous...@ti.com]
> Sent: Thursday, December 23, 2010 5:37 PM
> To: Gopinath, Thara
> Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> khil...@deeprootsystems.com; p...@pwsan.com; Sripathy,
> Vishwanath; Sawant, Anand; Menon, Nishanth
> Subject: Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for
> smartreflex modules.
>
> Hi Thara,
>
> On 12/20/2010 6:00 PM, Gopinath, Thara wrote:
> > From: Benoit Cousson
> >
> > This patch adds the hwmod details for OMAP4 smartreflex modules.
> >
> > Signed-off-by: Benoit Cousson
>
> You're s-o-b is missing, along with the changed you did to the patch.
>
> > ---
> > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 168
>
> > 1 files changed, 168 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > index 7367648..0a6e674 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > @@ -1740,6 +1740,169 @@ static struct omap_hwmod
> omap44xx_wd_timer3_hwmod = {
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > };
> >
> > +/*
> > + * 'smartreflex' class
> > + * smartreflex module (monitor silicon performance and outputs a
> measure of
> > + * performance error)
> > + */
> > +
> > +/* The IP is not compliant to type1 / type2 scheme */
> > +static struct omap_hwmod_sysc_fields
> omap_hwmod_sysc_type_smartreflex = {
> > + .sidle_shift= 24,
> > + .enwkup_shift = 26,
> > +};
> > +
> > +static struct omap_hwmod_class_sysconfig
> omap44xx_smartreflex_sysc = {
> > + .sysc_offs = 0x0038,
> > + .sysc_flags = (SYSC_HAS_ENAWAKEUP |
> SYSC_HAS_SIDLEMODE),
> > + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
>
> The newly added SIDLE_SMART_WKUP flag is missing.
>
> > + .sysc_fields=&omap_hwmod_sysc_type_smartreflex,
> > +};
> > +
> > +static struct omap_hwmod_class
> omap44xx_smartreflex_hwmod_class = {
> > + .name = "smartreflex",
> > + .sysc =&omap44xx_smartreflex_sysc,
> > + .rev = 2,
> > +};
> > +
> > +/* smartreflex_core */
> > +static struct omap_hwmod omap44xx_smartreflex_core_hwmod;
> > +static struct omap_hwmod_irq_info
> omap44xx_smartreflex_core_irqs[] = {
> > + { .irq = 19 + OMAP44XX_IRQ_GIC_START },
> > +};
> > +
> > +static struct omap_hwmod_addr_space
> omap44xx_smartreflex_core_addrs[] = {
> > + {
> > + .pa_start = 0x4a0dd000,
> > + .pa_end = 0x4a0dd03f,
> > + .flags = ADDR_TYPE_RT
> > + },
> > +};
> > +
> > +/* l4_cfg -> smartreflex_core */
> > +static struct omap_hwmod_ocp_if
> omap44xx_l4_cfg__smartreflex_core = {
> > + .master =&omap44xx_l4_cfg_hwmod,
> > + .slave =&omap44xx_smartreflex_core_hwmod,
> > + .clk= "l4_div_ck",
> > + .addr = omap44xx_smartreflex_core_addrs,
> > + .addr_cnt =
> ARRAY_SIZE(omap44xx_smartreflex_core_addrs),
> > + .user = OCP_USER_MPU | OCP_USER_SDMA,
> > +};
> > +
> > +/* smartreflex_core slave ports */
> > +static struct omap_hwmod_ocp_if
> *omap44xx_smartreflex_core_slaves[] = {
> > + &omap44xx_l4_cfg__smartreflex_core,
> > +};
> > +
> > +static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
> > + .name = "smartreflex_core",
> > + .class =&omap44xx_smartreflex_hwmod_class,
> > + .mpu_irqs = omap44xx_smartreflex_core_irqs,
> > + .mpu_irqs_cnt =
> ARRAY_SIZE(omap44xx_smartreflex_core_irqs),
> > + .main_clk = "smartreflex_core_fck",
> > + .vdd_name = "core",
> > + .prcm = {
> > + .omap4 = {
> > + .clkctrl_reg =
> OMAP4430_CM_ALWON_SR_CORE_CLKCTRL,
> > + },
> > + },
> > + .slaves = omap44xx_smartreflex_core_slaves,
> > + .slaves_cnt =
> ARRAY_SIZE(omap44xx_smartreflex_core_slaves),
> > + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > +};
> > +
> > +/* smartreflex_iva */
> > +static struct omap_hwmod omap44xx_smartreflex_iva_hwmod;
> > +static struct omap_hwmod_irq_info
> omap44xx_smartreflex_iva_irqs[] = {
> > + { .irq = 102 + OMAP44XX_IRQ_GIC_START },
> > +};
> > +
> > +static struct omap_hwmod_addr_space
> omap44xx_smartreflex_iva_addrs[] = {
> > + {
> > + .pa_start = 0x4a0db000,
> > + .pa_end = 0x4a0db03f,
> > + .flags = ADDR_TYPE_RT
> > + },
> > +};
> > +
> > +/* l4_cfg -> smartreflex_iva */
> > +static struct omap_hwmod_ocp_if
> omap44xx_l4_cfg__smartreflex_iva = {
> > + .master =&omap44xx_l4_cfg_hwmod,
> > + .slave =&omap44xx_smartreflex_iva_hwmod,
> > + .clk= "l4_div_ck",
> > + .addr = omap44xx_smartreflex_iva_addrs,
> > + .addr_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_addrs),
> > + .user = OCP_USER_MPU | OCP_USER_SDMA,
> > +};
> >
RE: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for smartreflex modules.
Nishant, > -Original Message- > From: Nishanth Menon [mailto:n...@ti.com] > Sent: Thursday, December 23, 2010 10:55 PM > To: Kevin Hilman > Cc: Vishwanath Sripathy; Benoit Cousson; Thara Gopinath; linux- > o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > p...@pwsan.com; Anand Sawant > Subject: Re: [PATCH v5 4/5] OMAP4: hwmod: Add inital data for > smartreflex modules. > > Kevin Hilman had written, on 12/23/2010 11:15 AM, the following: > > Vishwanath Sripathy writes: > > > > [...] > > > >>> Please note the following log when enabling SR in Class 3 on an > >>> OMAP4430/sdp: > >>> > >>> [2.362182] omap2_set_init_voltage: unable to find boot up OPP > for > >>> vdd_mpu > >>> [2.369384] omap2_set_init_voltage: Unable to put vdd_mpu to > its init > >>> voltage > >>> [2.369384] > >>> [2.378875] omap2_set_init_voltage: unable to find boot up OPP > for > >>> vdd_iva > >>> [2.386108] omap2_set_init_voltage: Unable to put vdd_iva to its > init > >>> voltage > >>> [2.386108] > >>> [2.396484] Power Management for TI OMAP4. > >>> [2.401031] sr_init: No PMIC hook to init smartreflex > >>> [2.406494] smartreflex smartreflex.0: omap_sr_probe: > SmartReflex > >>> driver initialized > >>> [2.414825] smartreflex smartreflex.1: omap_sr_probe: > SmartReflex > >>> driver initialized > >>> [2.423187] smartreflex smartreflex.2: omap_sr_probe: > SmartReflex > >>> driver initialized > >>> [2.431732] SmartReflex Class3 initialized > >>> > >>> Is it expected? > >>> Why do we have that blank line in-between? > >> I think turbo OPPs are disabled by default in OPP table where as > uboot is > >> setting mpu and iva to turbo OPP. That's why you are getting this > error. > > That explains the MPU OPPs, but only raises more questions. On what > > platforms was this tested? with *and* without turbo OPPs enabled? > Does > > the voltage layer properly initialized if the boot up OPP is not found, > > and the initial voltage is not set? > > > >> You should not get this error if you enable turbo opps in opp table. > If the platform SDP4430 is capable of booting up in higher (turbo) OPP, > that OPP should have been enabled in the board file! I have'nt seen a > patch for that yet > > > You would still get missing boot up OPP for IVA, as there are currenly > > no OMAP4 OPPs for IVA. Again, begging the question... how was this > > tested. > Further, why is SR enabled by default on this platform if it does not > have all domains available to be enabled (e.x. we dont have it on > PandaBoard even though it is OMAP4 rt?) Why do you think SR is enabled by default? The above log says that SR Module is initialized. However sr auto compensation is not started by default. Vishwa > > -- > Regards, > Nishanth Menon -- 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] omap3: Add basic support for 720MHz part
Kooi, > -Original Message- > From: Nishanth Menon [mailto:n...@ti.com] > Sent: Tuesday, January 18, 2011 10:19 PM > To: Koen Kooi > Cc: Sanjeev Premi; l-o List; th...@ti.com; Vishwanath Sripathy > Subject: Re: [PATCH] omap3: Add basic support for 720MHz part > > Koen Kooi wrote, on 01/18/2011 05:38 PM: > > > > Op 18 jan 2011, om 08:49 heeft Sanjeev Premi het volgende > geschreven: > > > >> This patch adds support for new speed enhanced parts with ARM > >> and IVA running at 720MHz and 520MHz respectively. These parts > >> can be probed at run-time by reading PRODID.SKUID[3:0] at > >> 0x4830A20C [1]. > >> > >> This patch specifically does following: > >> * Detect devices capable of 720MHz. > >> * Add new OPP > >> * Ensure that OPP is conditionally enabled. > >> * Check for presence of IVA before attempting to enable > >>the corresponding OPP. > > > > Thanks for the updated patch! > > > > I'm still having problem using this together with DVFS, the kernel > won't scale beyond 600MHz because 600MHz and 720MHz share the > same voltage. Thara, Nishant, do you have any suggestions on how to > convince the kernel that 2 frequencies can share the same voltage > settings? > + Vishwa Yes, this is a limitation with the current set of DVFS patches. With the next version of DVFS patches (will be out soon) this feature is going to be supported. That means you can have 2 opps with the same voltage but with different frequency. The device will be configured based on user requested frequency. Vishwa > > > > > If that isn't possible, should we lower the voltages for the lower opps > when detecting a 720MHz capable SoC? It would make sense that if > 720MHz works at X volt that 600MHz would work at less than X volt. (I > don't have a PDF reader at hand to check the TRM at the moment). > > > > Complete tree at http://dominion.thruhere.net/git/cgit.cgi/linux- > omap/log/?h=koen/beagle-next but this can be reproduced as well by > merging Thara's dvfs branch and applying Sanjeevs patch. > I suspect the problem lies here: > > http://dominion.thruhere.net/git/cgit.cgi/linux- > omap/tree/arch/arm/mach-omap2/voltage.c?h=koen/beagle- > next#n1847 > if two OPP frequencies have same voltage, the api introduced in > http://dominion.thruhere.net/git/cgit.cgi/linux- > omap/commit/?h=koen/beagle- > next&id=fd2991c20a8f770c7b8f5a29b3cbb17b9fca4768 > > will return back the first OPP entry which matches, which would be the > lower frequency as OPPs are organized in the OPP layer in increasing > order. > > -- > Regards, > Nishanth Menon -- 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] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
Tero,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Tero Kristo
> Sent: Tuesday, January 18, 2011 3:18 PM
> To: linux-omap@vger.kernel.org
> Cc: Paul Walmsley; Kevin Hilman
> Subject: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if doing
> so would reset an active clockdomain
>
> On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
> parts of the chip will be reset. If those parts of the chip are busy,
> the reset will disrupt them, causing unpredictable and generally
> undesirable results.
If some parts of the chip are busy, then how can Core domain enter off
state? The necessary condition for Core to enter low power state is that
all the clock domains (including DSS, CAM, IVA, USB, PER etc) should have
idled. Doesn't it mean that all the modules have idled and asserted
idleack when Core is entering off state?
Vishwa
>
> Signed-off-by: Tero Kristo
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 40
> +++-
> 1 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
> omap2/cpuidle34xx.c
> index f3e043f..d31b858 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -61,7 +61,7 @@ struct omap3_processor_cx {
> struct omap3_processor_cx
> omap3_power_states[OMAP3_MAX_STATES];
> struct omap3_processor_cx current_cx_state;
> struct powerdomain *mpu_pd, *core_pd, *per_pd;
> -struct powerdomain *cam_pd;
> +struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd, *usb_pd;
>
> /*
> * The latencies/thresholds for various C states have
> @@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct
> cpuidle_device *dev,
> {
> struct cpuidle_state *new_state = next_valid_state(dev, state);
> u32 core_next_state, per_next_state = 0, per_saved_state = 0;
> - u32 cam_state;
> + u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
> struct omap3_processor_cx *cx;
> int ret;
>
> @@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct
> cpuidle_device *dev,
>*its own code.
>*/
>
> + /* XXX Add CORE-active check here */
> +
> /*
>* Prevent idle completely if CAM is active.
>* CAM does not have wakeup capability in OMAP3.
> @@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct
> cpuidle_device *dev,
> (core_next_state > PWRDM_POWER_RET))
> per_next_state = PWRDM_POWER_RET;
>
> + /* XXX Add prevent-PER-off check here */
> +
> + /*
> + * If we are attempting CORE off, check if any other
> powerdomains
> + * are at retention or higher. CORE off causes chipwide reset
> which
> + * would reset these domains also.
> + */
> + if (core_next_state == PWRDM_POWER_OFF) {
> + iva2_state = pwrdm_read_pwrst(iva2_pd);
> + sgx_state = pwrdm_read_pwrst(sgx_pd);
> + usb_state = pwrdm_read_pwrst(usb_pd);
> + dss_state = pwrdm_read_pwrst(dss_pd);
> +
> + if (cam_state > PWRDM_POWER_OFF ||
> + dss_state > PWRDM_POWER_OFF ||
> + iva2_state > PWRDM_POWER_OFF ||
> + per_next_state > PWRDM_POWER_OFF ||
> + sgx_state > PWRDM_POWER_OFF ||
> + usb_state > PWRDM_POWER_OFF)
> + core_next_state = PWRDM_POWER_RET;
> + }
> +
> + /* Fallback to new target core/mpu state */
> + while (cx->core_state < core_next_state) {
> + state--;
> + cx = cpuidle_get_statedata(state);
> + }
> +
> + new_state = state;
> +
> /* Are we changing PER target state? */
> if (per_next_state != per_saved_state)
> pwrdm_set_next_pwrst(per_pd, per_next_state);
> @@ -489,6 +521,10 @@ int __init omap3_idle_init(void)
> core_pd = pwrdm_lookup("core_pwrdm");
> per_pd = pwrdm_lookup("per_pwrdm");
> cam_pd = pwrdm_lookup("cam_pwrdm");
> + dss_pd = pwrdm_lookup("dss_pwrdm");
> + iva2_pd = pwrdm_lookup("iva2_pwrdm");
> + sgx_pd = pwrdm_lookup("sgx_pwrdm");
> + usb_pd = pwrdm_lookup("usbhost_pwrdm");
>
> omap_init_power_states();
> cpuidle_register_driver(&omap3_idle_driver);
> --
> 1.7.1
>
> --
> 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] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
Tero,
> -Original Message-
> From: Vishwanath Sripathy [mailto:vishwanath...@ti.com]
> Sent: Wednesday, January 19, 2011 10:09 AM
> To: Tero Kristo; linux-omap@vger.kernel.org
> Cc: Paul Walmsley; Kevin Hilman
> Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
> doing so would reset an active clockdomain
>
> Tero,
>
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Tero Kristo
> > Sent: Tuesday, January 18, 2011 3:18 PM
> > To: linux-omap@vger.kernel.org
> > Cc: Paul Walmsley; Kevin Hilman
> > Subject: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
> doing
> > so would reset an active clockdomain
> >
> > On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many
> other
> > parts of the chip will be reset. If those parts of the chip are busy,
> > the reset will disrupt them, causing unpredictable and generally
> > undesirable results.
> If some parts of the chip are busy, then how can Core domain enter off
> state? The necessary condition for Core to enter low power state is that
> all the clock domains (including DSS, CAM, IVA, USB, PER etc) should
> have
> idled. Doesn't it mean that all the modules have idled and asserted
> idleack when Core is entering off state?
Besides these, Core off should reset the modules which are only in Core
domain. It should not impact other power domains. Also Core domain modules
which are reset will restore their context when Core comes out of off
mode. So why are you saying that "If those parts of the chip are busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results."?
Vishwa
>
> Vishwa
> >
> > Signed-off-by: Tero Kristo
> > Cc: Paul Walmsley
> > Cc: Kevin Hilman
> > ---
> > arch/arm/mach-omap2/cpuidle34xx.c | 40
> > +++-
> > 1 files changed, 38 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
> > omap2/cpuidle34xx.c
> > index f3e043f..d31b858 100644
> > --- a/arch/arm/mach-omap2/cpuidle34xx.c
> > +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> > @@ -61,7 +61,7 @@ struct omap3_processor_cx {
> > struct omap3_processor_cx
> > omap3_power_states[OMAP3_MAX_STATES];
> > struct omap3_processor_cx current_cx_state;
> > struct powerdomain *mpu_pd, *core_pd, *per_pd;
> > -struct powerdomain *cam_pd;
> > +struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd,
> *usb_pd;
> >
> > /*
> > * The latencies/thresholds for various C states have
> > @@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct
> > cpuidle_device *dev,
> > {
> > struct cpuidle_state *new_state = next_valid_state(dev, state);
> > u32 core_next_state, per_next_state = 0, per_saved_state = 0;
> > - u32 cam_state;
> > + u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
> > struct omap3_processor_cx *cx;
> > int ret;
> >
> > @@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct
> > cpuidle_device *dev,
> > *its own code.
> > */
> >
> > + /* XXX Add CORE-active check here */
> > +
> > /*
> > * Prevent idle completely if CAM is active.
> > * CAM does not have wakeup capability in OMAP3.
> > @@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct
> > cpuidle_device *dev,
> > (core_next_state > PWRDM_POWER_RET))
> > per_next_state = PWRDM_POWER_RET;
> >
> > + /* XXX Add prevent-PER-off check here */
> > +
> > + /*
> > +* If we are attempting CORE off, check if any other
> > powerdomains
> > +* are at retention or higher. CORE off causes chipwide reset
> > which
> > +* would reset these domains also.
> > +*/
> > + if (core_next_state == PWRDM_POWER_OFF) {
> > + iva2_state = pwrdm_read_pwrst(iva2_pd);
> > + sgx_state = pwrdm_read_pwrst(sgx_pd);
> > + usb_state = pwrdm_read_pwrst(usb_pd);
> > + dss_state = pwrdm_read_pwrst(dss_pd);
> > +
> > + if (cam_state > PWRDM_POWER_OFF ||
> > + dss_state > PWRDM_POWER_OFF ||
> > + iva2_state > PWRDM_POWER_OFF ||
> > + per_next_state > PWRDM_POWER_OFF ||
> > + sgx_state > PWRDM_POWER_OFF ||
> > + usb_state > PWRDM_POWER_OFF)
> > + core_next_state = PWRDM_POWER_RET;
> > + }
> > +
&g
RE: [PATCH] omap3: Add basic support for 720MHz part
Kooi,
> -Original Message-
> From: Koen Kooi [mailto:k...@dominion.thruhere.net]
> Sent: Tuesday, January 18, 2011 11:47 PM
> To: Vishwanath Sripathy
> Cc: Nishanth Menon; Sanjeev Premi; l-o List; Thara Gopinath
> Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
>
>
> Op 18 jan 2011, om 18:18 heeft Vishwanath Sripathy het volgende
> geschreven:
>
> > Kooi,
> >
> >> -Original Message-
> >> From: Nishanth Menon [mailto:n...@ti.com]
> >> Sent: Tuesday, January 18, 2011 10:19 PM
> >> To: Koen Kooi
> >> Cc: Sanjeev Premi; l-o List; th...@ti.com; Vishwanath Sripathy
> >> Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
> >>
> >> Koen Kooi wrote, on 01/18/2011 05:38 PM:
> >>>
> >>> Op 18 jan 2011, om 08:49 heeft Sanjeev Premi het volgende
> >> geschreven:
> >>>
> >>>> This patch adds support for new speed enhanced parts with ARM
> >>>> and IVA running at 720MHz and 520MHz respectively. These parts
> >>>> can be probed at run-time by reading PRODID.SKUID[3:0] at
> >>>> 0x4830A20C [1].
> >>>>
> >>>> This patch specifically does following:
> >>>> * Detect devices capable of 720MHz.
> >>>> * Add new OPP
> >>>> * Ensure that OPP is conditionally enabled.
> >>>> * Check for presence of IVA before attempting to enable
> >>>> the corresponding OPP.
> >>>
> >>> Thanks for the updated patch!
> >>>
> >>> I'm still having problem using this together with DVFS, the kernel
> >> won't scale beyond 600MHz because 600MHz and 720MHz share the
> >> same voltage. Thara, Nishant, do you have any suggestions on how
> to
> >> convince the kernel that 2 frequencies can share the same voltage
> >> settings?
> >> + Vishwa
> > Yes, this is a limitation with the current set of DVFS patches.
> > With the next version of DVFS patches (will be out soon) this feature
is
> > going to be supported. That means you can have 2 opps with the same
> > voltage but with different frequency. The device will be configured
> based
> > on user requested frequency.
>
> Just to have a crude hack, would something like this work?:
>
> /* MPU OPP6 */
> - OPP_INITIALIZER("mpu", false, 72000, 135),
> + OPP_INITIALIZER("mpu", false, 72000, 1350001),
>
> Or will I fall into a (post)divider trap where the kernel panics because
it
> can't do that exact voltage?
>
> The TRM[1] chickens out with the OPP definitions:
>
>
-->8--
--
> ---
> Six generic processor OPPs can be defined as:
> 1. OPP6 (VDD1 = v4, (MPU_CLK = fmpu5, IVA2_CLK = fiva5))
> 2. OPP5 (VDD1 = v4, (MPU_CLK = fmpu4, IVA2_CLK = fiva4))
> 3. OPP4 (VDD1 = v3, (MPU_CLK = fmpu3, IVA2_CLK = fiva3))
> 4. OPP3 (VDD1 = v2 , (MPU_CLK = fmpu2, IVA2_CLK = fiva2))
> 5. OPP2 (VDD1 = v1 , (MPU_CLK = fmpu1, IVA2_CLK = fiva1))
> 6. OPP1 (VDD1 = v0 , (MPU_CLK = fmpu0, IVA2_CLK = fiva0))
> where v4 > v3 > v2 > v1 > v0,
>
--8<--
--
> ---
>
> My limited sample size of 3 board (2x beagle C4, 1x overo tide) shows
> 600MHz@1.3V works as well, but I don't know how much slack that has.
> And I haven't check if the hardware can do 1.3V exactly or has rounded
> up.
>
> So, what's the quickest way with the current code to get 720MHz
> "working"? I've voided my warranty on everything already, so that isn't
a
> problem :)
If you want a quick hack, you can modify the voltage for 700M marginally
(like you have done above). But it needs to be done in multiple places.
You need to modify IVA OPP6 entry in opp table and OPP6 voltage value in
voltage.h as well besides above change. This should work.
Vishwa
>
> regards,
>
> Koen
>
> [1] spruf98m.pdf page 355
--
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: Fail to suspend to ram: "Class driver suspend failed for cpu0"
Luke, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Luke Gong > Sent: Friday, January 21, 2011 5:03 AM > To: Kevin Hilman > Cc: linux-omap@vger.kernel.org > Subject: Re: Fail to suspend to ram: "Class driver suspend failed for > cpu0" > > Thanks, Kevin. > > On Thu, Jan 20, 2011 at 5:54 PM, Kevin Hilman > wrote: > > Luke Gong writes: > > > >> I have a beagle board with OMAP3530. I ported linux-omap- > pm2.6.32 to > >> this board. When I want to let it suspend to ram, > > > > This is an old kernel. Any reason you're not using a newer kernel? > > I have Angstrom7 with kernel 2.6.32 running on this board. So I > selected this old version to test. I might try the latest one. > > > > >> it fails and I get > >> the message "Class driver suspend failed for cpu0" > > > > This is the CPUfreq driver failing to suspend, probably because there is > > no CPUfreq driver implemented in your kernel. Try disabling > CPU_FREQ in > > your kernel config. > > It seems can suspend to ram after disabling CPU_FREQ. Here is the log: > > root@beagleboard:~# echo mem > /sys/power/state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > > ** > *** > Once I hit the keyboard, I get: > > root@beagleboard:~# echo mem > /sys/power/state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > omapfb omapfb: timeout waiting for FRAME DONE > Powerdomain (core_pwrdm) didn't enter target state 1 > Powerdomain (cam_pwrdm) didn't enter target state 1 > Powerdomain (per_pwrdm) didn't enter target state 1 > Could not enter target state in pm_suspend > Restarting tasks ... done. > root@beagleboard:~# > *** > > I am just curious why the powerdomain didn't enter target state 1. It looks like your camera module is not idling upon suspend preventing per and core to idle. Pls check whether camera driver has implemented suspend/resume hooks properly. OR you can disable camera module and try. > > Another issue is about CPU frequency scaling. Using the original > Angstrom7, I can scale CPU frequency. But with the linux-omap-pm > kernel, I cannot do it even though I enable this feature in the config > file. Is there any solution to support both cpu frequency scaling and > suspend to ram? In current linux-omap-pm branch, DVFS feature is not supported and this work is under progress. Previously DVFS feature was supported in pm branch using SRF and it has been removed sometime back. If you really want cpufreq support, you can pick DVFS patches under review available at: https://patchwork.kernel.org/patch/290542/ It's also available in the dvfs tree hosted@ http://dev.omapzoom.org/?p=thara/omap-dvfs.git;a=shortlog;h=refs/heads/pm- dvfs Vishwa > > Thanks again for your help. > > > > Kevin > > > >> . Here is the log: > >> > >> root@beagleboard:~# echo mem > /sys/power/state > >> PM: Syncing filesystems ... done. > >> Freezing user space processes ... (elapsed 0.00 seconds) done. > >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > >> Suspending console(s) (use no_console_suspend to debug) > >> omapfb omapfb: timeout waiting for FRAME DONE > >> Class driver suspend failed for cpu0 > >> Restarting tasks ... done. > >> > >> * > >> > >> Is there any idea to fix this problem? Thanks. > > > > > > -- > Luke > -- > 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 00/13] OMAP: Basic DVFS Framework
Balbi, > -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Saturday, January 22, 2011 10:48 PM > To: Vishwanath BS > Cc: linux-omap@vger.kernel.org; patc...@linaro.org > Subject: Re: [PATCH 00/13] OMAP: Basic DVFS Framework > > Hi, > > On Fri, Jan 21, 2011 at 07:30:52PM +0530, Vishwanath BS wrote: > > This patch series introduces support for Dynamic Voltage and > Frequency Scaling > > (DVFS) for OMAP devices. > > > > For detailed design details, refer to DVFS Documentation. > > If this is supposed to be used by drivers I would rather not as it's yet > another OMAP-specific API to use. > > Before you reply with "you can pass function pointers via platform_data" > let me say that even that is a burden, specially on devices which are > used by several archs. > > Why don't you make it more generic like the OPP layer was created ? > Isn't it better to just build on top of the OPP layer and make this one > also generic ? I do not think DVFS layer can be made a generic layer outside OMAP because of the fact that DVFS is closely coupled with OMAP device layer (for getting hwmod related data and clock handling), OMAP voltage layer (for voltage scaling and handling of dependency voltage domains) and smart reflex layer. Vishwa > > -- > balbi -- 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 00/13] OMAP: Basic DVFS Framework
Balbi, > -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Monday, January 24, 2011 11:49 AM > To: Vishwanath Sripathy > Cc: ba...@ti.com; linux-omap@vger.kernel.org; patc...@linaro.org > Subject: Re: [PATCH 00/13] OMAP: Basic DVFS Framework > > Hi, > > On Mon, Jan 24, 2011 at 11:31:20AM +0530, Vishwanath Sripathy > wrote: > > I do not think DVFS layer can be made a generic layer outside OMAP > because > > of the fact that DVFS is closely coupled with OMAP device layer (for > > getting hwmod related data and clock handling), OMAP voltage layer > (for > > voltage scaling and handling of dependency voltage domains) and > smart > > reflex layer. > > that an implementation detail. If you: > > a. make the DVFS layer so that you need a HW-glue layer which > will use OMAP-specific APIs; or > > b. pass function pointers for the generic DVFS layer to use > > (note that I'd rather have option (a)), you solve the problem, no ? It is not just implementation. Even the underlying design of DVFS is closely coupled with these layers. If we try to split this DVFS framework into generic and OMAP specific part, then the flow will become too cumbersome since there are will be too many interactions between common and OMAP part. Also it will reduce the code readability aspect as well. I do not think it's worth adding some much of complexity and effort just to avoid a driver using platform specific function pointers to call these APIs. Vishwa > > -- > balbi -- 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: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
Jean,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Jean Pihet
> Sent: Monday, January 24, 2011 7:59 PM
> To: linux-omap@vger.kernel.org
> Cc: Jean Pihet
> Subject: Re: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
>
> On Thu, Jan 13, 2011 at 5:19 PM, wrote:
> > From: Jean Pihet
> >
> > Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
> > is copied to internal SRAM and run from there.
> > However only a small part of the code really needs to run from
internal
> SRAM.
> >
> > This fix lets most of the ASM idle code run from the DDR
> > in order to minimize the SRAM usage. No performance
> > loss or gain can be measured with a 32KHz clock period.
> >
> > The only pieces of code that are mandatory in SRAM
> > are:
> > - the i443 erratum WA,
> > - the i581 erratum WA,
> > - the security extension code.
> >
> > SRAM usage:
> > - original code:
> > . 560 bytes for omap3_sram_configure_core_dpll (used by DVFS),
> > . 1368 bytes for omap_sram_idle (used by suspend/resume in
> RETention),
> > . 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode
> on ES3.x),
> > . 108 bytes for save_secure_ram_context (used on HS parts).
> >
> > With this fix the usage for suspend/resume in RETention goes down
> 312 bytes, so the
> > gain in SRAM usage for suspend/resume is > 1KB.
> >
> > Tested on OMAP3EVM, Beagleboard (ES2.x) and N900 (ES3.1)
> > in idle with full RET and OFF modes.
> >
> > Signed-off-by: Jean Pihet
>
> Is there any feedback on this code?
> This change would need some more testing on all OMAP3 platforms,
> especially on the 36xx platforms that I do not have at hand.
I tested this patch on ZOOM3 (OMAP3630) using kevin's PM branch for both
retention and off in CPUIdle and suspend path and it seems to work fine.
You can add
Tested-by: Vishwanath BS
Vishwa
>
> Comments are welcome!
>
> Regards,
> Jean
>
> > ---
> > arch/arm/mach-omap2/pm.h | 19 ++-
> > arch/arm/mach-omap2/pm34xx.c | 19 ++-
> > arch/arm/mach-omap2/sleep34xx.S | 299
> +++
> > 3 files changed, 200 insertions(+), 137 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-
> omap2/pm.h
> > index 1c1b0ab..ae9dec0 100644
> > --- a/arch/arm/mach-omap2/pm.h
> > +++ b/arch/arm/mach-omap2/pm.h
> > @@ -87,18 +87,29 @@ extern int pm_dbg_regset_init(int reg_set);
> > #define pm_dbg_regset_init(reg_set) do {} while (0);
> > #endif /* CONFIG_PM_DEBUG */
> >
> > +/* 24xx */
> > extern void omap24xx_idle_loop_suspend(void);
> > +extern unsigned int omap24xx_idle_loop_suspend_sz;
> >
> > extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem
> *sdrc_dlla_ctrl,
> > void __iomem *sdrc_power);
> > +extern unsigned int omap24xx_cpu_suspend_sz;
> > +
> > +/* 3xxx */
> > extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
> > +
> > +/* omap3_do_wfi function pointer and size, for copy to SRAM */
> > +extern void omap3_do_wfi(void);
> > +extern unsigned int omap3_do_wfi_sz;
> > +/* ... and its pointer from SRAM after copy */
> > +extern void (*omap3_do_wfi_sram)(void);
> > +
> > +/* save_secure_ram_context function pointer and size, for copy to
> SRAM */
> > extern void save_secure_ram_context(u32 *addr);
> > -extern void omap3_save_scratchpad_contents(void);
> >
> > -extern unsigned int omap24xx_idle_loop_suspend_sz;
> > extern unsigned int save_secure_ram_context_sz;
> > -extern unsigned int omap24xx_cpu_suspend_sz;
> > -extern unsigned int omap34xx_cpu_suspend_sz;
> > +
> > +extern void omap3_save_scratchpad_contents(void);
> >
> > #define PM_RTA_ERRATUM_i608 (1 << 0)
> > #define PM_SDRC_WAKEUP_ERRATUM_i583 (1 << 1)
> > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
> omap2/pm34xx.c
> > index 5b323f2..56ca3cb 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -82,9 +82,8 @@ struct power_state {
> >
> > static LIST_HEAD(pwrst_list);
> >
> > -static void (*_omap_sram_idle)(u32 *addr, int save_state);
> > -
> > static int (*_omap_save_secure_sram)(u32 *addr);
> > +void (*omap3_do_wfi_sram)(void);
> >
> > static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> > static struct powerdomain *core_pwrdm, *per_pwrdm;
> > @@ -355,9 +354,6 @@ void omap_sram_idle(void)
> > int core_prev_state, per_prev_state;
> > u32 sdrc_pwr = 0;
> >
> > - if (!_omap_sram_idle)
> > - return;
> > -
> > pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
> > pwrdm_clear_all_prev_pwrst(neon_pwrdm);
> > pwrdm_clear_all_prev_pwrst(core_pwrdm);
> > @@ -439,7 +435,7 @@ void omap_sram_idle(void)
> > * get saved. The restore path then reads from this
> > * location and restores them back.
> > */
> > - _omap_sram_idle(omap3_arm_context, save_state);
> > + omap34xx_cpu_suspend(omap3_arm_context, save_state);
> >
RE: [query] smartreflex: No PMIC hook to init smartreflex
Nishant,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, January 27, 2011 3:06 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [query] smartreflex: No PMIC hook to init smartreflex
>
> Sanjeev,
>
> On Tue, Jan 25, 2011 at 20:55, Premi, Sanjeev wrote:
> > While building the kernel at 2.6.37, i see this warning for omap3evm -
> with omap3630:
> >
> > Power Management for TI OMAP3.
> > sr_init: No PMIC hook to init smartreflex <-- THIS IS THE WARNING.
> > smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver
> initialized
> > smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver
> initialized
> > SmartReflex Class3 initialized
> >
> > In the code, i see this comment:
> > /*
> > * sr_init is a late init. If by then a pmic specific API is not
> > * registered either there is no need for anything to be done on
> > * the PMIC side or somebody has forgotten to register a PMIC
> > * handler. Warn for the second condition.
> > */
> > if (sr_pmic_data && sr_pmic_data->sr_pmic_init)
> > sr_pmic_data->sr_pmic_init();
> > else
> > pr_warning("%s: No PMIC hook to init smartreflex\n", __func__);
> >
> > But, I couldn't find any place where PMIC is being registered.
>
> This is a harmless warning (ideally, we should remove the pr_warning).
> the intent here is to have hook for pmic_init which could be
> populated for custom PMICs which may need "something additional" for
> Smart reflex enablement. if you look at the sr_pmic_data - it just has
> a single api for pmic_init
>
> e.g. in the case of TWL4030/5030, we might need to set the bit to
> switch mode from I2C1 to I2C_SR - e.g. the patch from Shweta[1]
>
> if Smartreflex AVS was the *only* mechanism in the system, we could
> have hooked pmic_init to this bit setting. but since the system can do
> voltage scaling (VP forceupdate/vc bypass) independent of SR AVS
> block, the patch in [1] does initialization independent of
> sr_pmic_data->pmic_init which makes sense.
>
> in short, my 2cents: the warning is probably something we should
> remove from the code.
As you mentioned, incase of TWL4030/5030, we do not need any hook. However
if some other PMIC is used that genuinely needs this hook, then shouldn't
SR throw up this warning? As SR module is independent of PMIC, it cannot
distinguish them. So I feel this warning should be present probably
reworded better like "No PMIC hook registered to init smartreflex. Either
this PM IC does not need SR init or PMIC hook is missing".
Vishwa
>
> [1] http://marc.info/?l=linux-omap&m=129584746102725&w=2
> Regards,
> Nishanth Menon
> --
> 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 10/13] OMAP3: Add voltage dependency table for VDD1.
Kevin,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Saturday, January 29, 2011 6:01 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath
> Subject: Re: [PATCH 10/13] OMAP3: Add voltage dependency table for
> VDD1.
>
> Hi Vishwa,
>
> Vishwanath BS writes:
>
> > From: Thara Gopinath
> >
> > In OMAP3, for perfomrance reasons when VDD1 is at voltage above
> > 1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
> > patch introduce this cross VDD dependency for OMAP3 VDD1.
> >
> > Signed-off-by: Thara Gopinath
>
> As you are now on the delivery path, your signoff should be here as
> well.
OK
>
> Some initial tests on 34xx turned up errors when trying to scale
> voltage:
>
>omap_voltage_get_voltdata: Unable to match the current voltage with
> the voltagetable for vdd_core
>
> First, this error message wasn't very useful since I had no idea what
> the "current" voltage was. Also, "current voltage" probably isn't the
> right word since to me, current voltage means the one currently set.
> This is actually the target voltage that is being looked up.
Agreed. Will fix it in the next version.
>
> In any case, root cause below...
>
> > This patch has checkpatch warnings for line over 80 chars. It is not
> fixed for
> > code readability.
>
> OK, this can either be left out, or added below the '---' as it's not
> needed in the final git history.
OK
>
> > ---
> > arch/arm/mach-omap2/voltage.c | 42
> +++-
> > 1 files changed, 40 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
> omap2/voltage.c
> > index 92fe20d..8881c0c 100644
> > --- a/arch/arm/mach-omap2/voltage.c
> > +++ b/arch/arm/mach-omap2/voltage.c
> > @@ -191,6 +191,39 @@ static struct omap_volt_data
> omap44xx_vdd_core_volt_data[] = {
> > VOLT_DATA_DEFINE(0, 0, 0, 0),
> > };
> >
> > +/* OMAP 3430 MPU Core VDD dependency table */
> > +static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
> > + {.main_vdd_volt = OMAP3430_VDD_MPU_OPP1_UV,
> .dep_vdd_volt = OMAP4430_VDD_CORE_OPP50_UV},
> > + {.main_vdd_volt = OMAP3430_VDD_MPU_OPP2_UV,
> .dep_vdd_volt = OMAP4430_VDD_CORE_OPP50_UV},
> > + {.main_vdd_volt = OMAP3430_VDD_MPU_OPP3_UV,
> .dep_vdd_volt = OMAP4430_VDD_CORE_OPP100_UV},
> > + {.main_vdd_volt = OMAP3430_VDD_MPU_OPP4_UV,
> .dep_vdd_volt = OMAP4430_VDD_CORE_OPP100_UV},
> > + {.main_vdd_volt = OMAP3430_VDD_MPU_OPP5_UV,
> .dep_vdd_volt = OMAP4430_VDD_CORE_OPP100_UV},
> > + {.main_vdd_volt = 0, .dep_vdd_volt = 0},
> > +};
>
> This 34xx table has 4430 OPP voltages for CORE, which are clearly not
> right. 34xx has 3 CORE voltages to pick from, so I'm not sure which
> ones are right
>
> Please update this with the correct 34xx voltages and also validate on
> 34xx also.
Yes, will fix it.
Regarding 34xx testing, I did try to test it on 3430 SDP. However image
was not booting up when I used pm branch.
I see that with latest pm-core branch image boots up where as with pm
branch it does not. Is this a known issue?
Vishwa
>
> Thanks,
>
> Kevin
>
>
> > +static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
> > + {
> > + .name = "core",
> > + .dep_table = omap34xx_vdd1_vdd2_data,
> > + },
> > +};
> > +
> > +/* OMAP 3630 MPU Core VDD dependency table */
> > +static struct omap_vdd_dep_volt omap36xx_vdd1_vdd2_data[] = {
> > + {.main_vdd_volt = OMAP3630_VDD_MPU_OPP50_UV,
> .dep_vdd_volt = OMAP3630_VDD_CORE_OPP50_UV},
> > + {.main_vdd_volt = OMAP3630_VDD_MPU_OPP100_UV,
> .dep_vdd_volt = OMAP3630_VDD_CORE_OPP100_UV},
> > + {.main_vdd_volt = OMAP3630_VDD_MPU_OPP120_UV,
> .dep_vdd_volt = OMAP3630_VDD_CORE_OPP100_UV},
> > + {.main_vdd_volt = OMAP3630_VDD_MPU_OPP1G_UV,
> .dep_vdd_volt = OMAP3630_VDD_CORE_OPP100_UV},
> > + {.main_vdd_volt = 0, .dep_vdd_volt = 0},
> > +};
> > +
> > +static struct omap_vdd_dep_info omap36xx_vdd1_dep_info[] = {
> > + {
> > + .name = "core",
> > + .dep_table = omap36xx_vdd1_vdd2_data,
> > + },
> > +};
> > +
> > static struct dentry *voltage_dir;
> >
> > /* Init function pointers */
> > @@ -696,10 +729,15 @@ static int __init
> omap3_vdd_data_configure(struct omap_vdd_info *vdd)
> > }
> >
> > if (!strcmp(vdd->voltdm.name, "mpu")) {
> > - if (cpu_is_omap3630())
> > + if (cpu_is_omap3630()) {
> > vdd->volt_data = omap36xx_vddmpu_volt_data;
> > - else
> > + vdd->dep_vdd_info = omap36xx_vdd1_dep_info;
> > + vdd->nr_dep_vdd =
> ARRAY_SIZE(omap36xx_vdd1_dep_info);
> > + } else {
> > vdd->volt_data = omap34xx_vddmpu_volt_data;
> > + vdd->dep_vdd_info = omap34xx_vdd1_dep_info;
> > + vdd->nr_dep_vdd =
> ARRAY_SIZE(omap34xx_vdd1_dep_info);
> > + }
> >
> > vdd->vp_reg.tranxdone_status =
> OMAP3430_VP1_TRANXDONE_
RE: [PATCH 00/13] OMAP: Basic DVFS Framework
Ping. Vishwa > -Original Message- > From: Vishwanath BS [mailto:vishwanath...@ti.com] > Sent: Friday, January 21, 2011 7:31 PM > To: linux-omap@vger.kernel.org > Cc: patc...@linaro.org; Vishwanath BS > Subject: [PATCH 00/13] OMAP: Basic DVFS Framework > > This patch series introduces support for Dynamic Voltage and Frequency > Scaling > (DVFS) for OMAP devices. > > For detailed design details, refer to DVFS Documentation. > > Pending Work: > 1. OMAP4 support > > Changes done in this series: > 1. Seperated DVFS code from Voltage layer (voltage.c) and introduced > DVFS layer >in dvfs.c > 2. Added support for frequency throttling and frequency locking (by > introducing >frequency list per device) > 3. Added changes in omap cpufreq driver for DVFS support > 4. Fixed race condition issues in DVFS layer > 5. Added documentation for DVFS framework > 5. Addressed comments received on V2 > V1: https://patchwork.kernel.org/patch/120132/ > V2: https://patchwork.kernel.org/patch/290542/ > > Contributors to conceptualization of the design include > Anand Sawant > Benoit Cousson , > Kevin Hilman , > Paul Wamsley , > Parthasarathy Basak > Thara Gopinath > Vishwanath Sripathy > > This patch series is generated against latest kevin's pm branch and has > been > tested on ZOOM3 for mpu, iva and core DVFS. > > Thara Gopinath (6): > OMAP: Introduce device specific set rate and get rate in omap_device > structure > OMAP3: Introduce custom set rate and get rate APIs for scalable > OMAP: Disable Smartreflex across DVFS > devices > OMAP3: Introduce voltage domain info in the hwmod structures. > OMAP3: Add voltage dependency table for VDD1. > OMAP2PLUS: Enable various options in defconfig > > Vishwanath BS (7): > OMAP: Introduce accessory APIs for DVFS > OMAP: Implement Basic DVFS > OMAP: Introduce dependent voltage domain support > OMAP: Introduce device scale implementation > OMAP3: cpufreq driver changes for DVFS support > OMAP2PLUS: Replace voltage values with Macros > OMAP: Add DVFS Documentation > > Documentation/arm/OMAP/omap_dvfs | 111 > arch/arm/configs/omap2plus_defconfig |4 + > arch/arm/mach-omap2/Makefile |2 +- > arch/arm/mach-omap2/dvfs.c| 751 > + > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|3 + > arch/arm/mach-omap2/opp3xxx_data.c| 47 +- > arch/arm/mach-omap2/opp4xxx_data.c| 13 +- > arch/arm/mach-omap2/pm.c | 71 +++ > arch/arm/mach-omap2/voltage.c | 159 ++ > arch/arm/plat-omap/cpu-omap.c | 35 +- > arch/arm/plat-omap/include/plat/dvfs.h| 34 ++ > arch/arm/plat-omap/include/plat/omap_device.h |9 + > arch/arm/plat-omap/include/plat/voltage.h | 148 + > arch/arm/plat-omap/omap_device.c | 58 ++ > 14 files changed, 1293 insertions(+), 152 deletions(-) > create mode 100644 Documentation/arm/OMAP/omap_dvfs > create mode 100644 arch/arm/mach-omap2/dvfs.c > create mode 100644 arch/arm/plat-omap/include/plat/dvfs.h -- 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] arm: mach-omap2: smartreflex: fix another memory leak
> -Original Message- > From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- > kernel-boun...@lists.infradead.org] On Behalf Of Aaro Koskinen > Sent: Monday, February 07, 2011 6:28 PM > To: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Cc: Aaro Koskinen > Subject: [PATCH] arm: mach-omap2: smartreflex: fix another memory > leak > > Temporary strings with volt_* file names should be released after the > debugfs entries are created. > > The patch eliminates kmemleak reports with the following stack trace > (multiple objects depending on HW): > > unreferenced object 0xcedbc5a0 (size 64): > comm "swapper", pid 1, jiffies 4294929375 (age 423.734s) > hex dump (first 32 bytes): > 76 6f 6c 74 5f 39 37 35 30 30 30 00 00 00 00 00 volt_975000. > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > backtrace: > [] create_object+0x104/0x208 > [] kmem_cache_alloc_trace+0xf0/0x17c > [] omap_sr_probe+0x314/0x420 > [] platform_drv_probe+0x18/0x1c > [] driver_probe_device+0xc8/0x188 > [] __driver_attach+0x68/0x8c > [] bus_for_each_dev+0x44/0x74 > [] bus_add_driver+0xa0/0x228 > [] driver_register+0xa8/0x130 > [] platform_driver_probe+0x18/0x8c > [] sr_init+0x40/0x74 > [] do_one_initcall+0xc8/0x1a0 > [] kernel_init+0x150/0x218 > [] kernel_thread_exit+0x0/0x8 > [] 0x > > Signed-off-by: Aaro Koskinen > --- > arch/arm/mach-omap2/smartreflex.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach- > omap2/smartreflex.c > index 77ecebf..61aebed 100644 > --- a/arch/arm/mach-omap2/smartreflex.c > +++ b/arch/arm/mach-omap2/smartreflex.c > @@ -942,6 +942,7 @@ static int __init omap_sr_probe(struct > platform_device *pdev) > strcat(name, volt_name); > (void) debugfs_create_x32(name, S_IRUGO | S_IWUGO, > nvalue_dir, > &(sr_info->nvalue_table[i].nvalue)); > + kfree(name); I feel there is no real need to allocate and free memory dynamically here when the size allocated is constant. Rather I would propose to create an array name of size NVALUE_NAME_LEN+1 and use it inside the loop. Vishwa > } > > return ret; > -- > 1.5.6.5 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 02/13] OMAP: Introduce device specific set rate and get rate in omap_device structure
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Friday, February 04, 2011 5:17 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath
> Subject: Re: [PATCH 02/13] OMAP: Introduce device specific set rate and
> get rate in omap_device structure
>
> Vishwanath BS writes:
>
> > From: Thara Gopinath
> >
> > This patch extends the omap_device structure to contain pointers to
> scale the
> > operating rate of the device and to retrieve the operating rate of the
> device.
> > This patch also adds the three new APIs in the omap device layer
> > namely omap_device_set_rate that can be called to set a new
> operating
> > rate for a device, omap_device_get_rate that can be called to retrieve
> > the operating frequency for a device and
> omap_device_register_dvfs_callbacks
> > to register the device specific set_rate and get_rate functions.
> > The omap_device_set_rate and omap_device_get_rate does some
> routine error
> > checks and finally calls into the device specific set_rate
> > and get_rate APIs populated through omap_device_populate_rate_fns.
> >
> > Signed-off-by: Thara Gopinath
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/plat-omap/include/plat/omap_device.h |9 +
> > arch/arm/plat-omap/omap_device.c | 49
> +
> > 2 files changed, 58 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
> b/arch/arm/plat-omap/include/plat/omap_device.h
> > index e4c349f..204fb0a 100644
> > --- a/arch/arm/plat-omap/include/plat/omap_device.h
> > +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> > @@ -50,6 +50,8 @@ extern struct device omap_device_parent;
> > * @hwmods: (one .. many per omap_device)
> > * @hwmods_cnt: ARRAY_SIZE() of @hwmods
> > * @pm_lats: ptr to an omap_device_pm_latency table
> > + * @set_rate: fn ptr to change the operating rate.
> > + * @get_rate: fn ptr to retrieve the current operating rate.
> > * @pm_lats_cnt: ARRAY_SIZE() of what is passed to @pm_lats
> > * @pm_lat_level: array index of the last odpl entry executed - -1 if
> never
> > * @dev_wakeup_lat: dev wakeup latency in nanoseconds
> > @@ -73,6 +75,8 @@ struct omap_device {
> > s8 pm_lat_level;
> > u8 hwmods_cnt;
> > u8 _state;
> > + int (*set_rate)(struct device *dev, unsigned long rate);
> > + unsigned long (*get_rate) (struct device *dev);
> > };
> >
> > /* Device driver interface (call via platform_data fn ptrs) */
> > @@ -107,6 +111,11 @@ void __iomem
> *omap_device_get_rt_va(struct omap_device *od);
> > int omap_device_align_pm_lat(struct platform_device *pdev,
> > u32 new_wakeup_lat_limit);
> > struct powerdomain *omap_device_get_pwrdm(struct omap_device
> *od);
> > +int omap_device_set_rate(struct device *dev, unsigned long freq);
> > +unsigned long omap_device_get_rate(struct device *dev);
> > +void omap_device_register_dvfs_callbacks(struct device *dev,
> > + int (*set_rate)(struct device *dev, unsigned long rate),
> > + unsigned long (*get_rate) (struct device *dev));
> > u32 omap_device_get_context_loss_count(struct platform_device
> *pdev);
> >
> > /* Other */
> > diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
> omap/omap_device.c
> > index a84e849..4cee430 100644
> > --- a/arch/arm/plat-omap/omap_device.c
> > +++ b/arch/arm/plat-omap/omap_device.c
> > @@ -810,6 +810,55 @@ int omap_device_enable_clocks(struct
> omap_device *od)
> > return 0;
> > }
> >
> > +int omap_device_set_rate(struct device *dev, unsigned long freq)
> > +{
> > + struct platform_device *pdev;
> > + struct omap_device *od;
> > +
> > + pdev = container_of(dev, struct platform_device, dev);
>
> There is a macro for this in device.h:
>
> pdev = to_platform_device(dev)
>
> This needs to be fixed all over this series.
OK. Will fix it in next vesion.
>
> > + od = _find_by_pdev(pdev);
> > +
> > + if (!od->set_rate) {
> > + dev_err(dev, "%s: No set_rate API for scaling device\n",
> > + __func__);
> > + return -ENODATA;
> > + }
> > +
> > + return od->set_rate(dev, freq);
> > +}
> > +
> > +unsigned long omap_device_get_rate(struct device *dev)
> > +{
> > + struct platform_device *pdev;
> > + struct omap_device *od;
> > +
> > + pdev = container_of(dev, struct platform_device, dev);
> > + od = _find_by_pdev(pdev);
>
> Should also check here for a valid omap_device, but making sure its
> parent is omap_device_parent.
OK
>
> > +
> > +
> > + if (!od->get_rate) {
> > + dev_err(dev, "%s: No get rate API for the device\n",
> > + __func__);
> > + return 0;
> > + }
> > +
> > + return od->get_rate(dev);
> > +}
> > +
> > +void omap_device_register_dvfs_callbacks(struct device *dev,
> > + int (*set_rate)(struc
RE: [PATCH 03/13] OMAP: Implement Basic DVFS
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Friday, February 04, 2011 6:44 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath
> Subject: Re: [PATCH 03/13] OMAP: Implement Basic DVFS
>
> Vishwanath BS writes:
>
> > This patch introduces an API to perform DVFS for a given voltage
> domain.
> > It takes omap_vdd_dvfs_info pointer as input parameter, computes
> the highest
> > requested voltage for that vdd and scales all the devices in that vdd
to
> the
> > requested frequency along with voltage scaling.
> >
> > Based on original patch from Thara.
> >
> > Signed-off-by: Vishwanath BS
> > Cc: Thara Gopinath
> > ---
> > arch/arm/mach-omap2/dvfs.c | 87
> +++-
> > 1 files changed, 86 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-
> omap2/dvfs.c
> > index 8832e4a..cefc2be 100755
> > --- a/arch/arm/mach-omap2/dvfs.c
> > +++ b/arch/arm/mach-omap2/dvfs.c
> > @@ -21,7 +21,7 @@
> > #include
> >
> > /**
> > - * struct omap_dev_user_list - Structure maitain userlist per devide
> > + * struct omap_dev_user_list - Structure maitain userlist per device
>
> this typo should be done in the original patch, not here.
OK
>
> > *
> > * @dev: The device requesting for a particular frequency
> > * @node: The list head entry
> > @@ -413,6 +413,91 @@ static int
> omap_dvfs_remove_freq_request(struct omap_vdd_dvfs_info *dvfs_info,
> > }
> >
> > /**
> > + * omap_dvfs_voltage_scale() : API to scale the devices associated
> with a
> > + * voltage domain vdd
voltage.
>
> This function scales both voltage and frequency, so the name
> voltage_scale() is a bit misleading.
Does omap_dvfs_do_dvfs look good?
>
> > + * @dvfs_info: omap_vdd_dvfs_info pointer for the required vdd
> > + *
> > + * This API runs through the list of devices associated with the
> > + * voltage domain and scales the device rates to the one requested
> > + * by the user or those corresponding to the new voltage of the
> > + * voltage domain. Target voltage is the highest voltage in the
> vdd_user_list.
> > + *
> > + * Returns 0 on success
> > + * else the error value.
> > + */
> > +static int omap_dvfs_voltage_scale(struct omap_vdd_dvfs_info
> *dvfs_info)
> > +{
> > + unsigned long curr_volt;
> > + int is_volt_scaled = 0;
>
> should be a bool
ok
>
> > + struct omap_vdd_dev_list *temp_dev;
> > + struct plist_node *node;
> > + int ret = 0;
> > + struct voltagedomain *voltdm;
> > + unsigned long volt;
> > +
> > + if (!dvfs_info || IS_ERR(dvfs_info)) {
> > + pr_warning("%s: VDD specified does not exist!\n",
> __func__);
> > + return -EINVAL;
> > + }
> > +
> > + voltdm = dvfs_info->voltdm;
> > +
> > + mutex_lock(&dvfs_info->scaling_mutex);
> > +
> > + /* Find the highest voltage being requested */
> > + node = plist_last(&dvfs_info->user_list);
> > + volt = node->prio;
> > +
> > + curr_volt = omap_voltage_get_nom_volt(voltdm);
> > +
> > + if (curr_volt == volt) {
> > + is_volt_scaled = 1;
> > + } else if (curr_volt < volt) {
> > + ret = omap_voltage_scale_vdd(voltdm, volt);
> > + if (ret) {
> > + pr_warning("%s: Unable to scale the %s to %ld
> volt\n",
> > + __func__, voltdm->name,
> volt);
> > + mutex_unlock(&dvfs_info->scaling_mutex);
> > + return ret;
> > + }
> > + is_volt_scaled = 1;
> > + }
> > +
> > + list_for_each_entry(temp_dev, &dvfs_info->dev_list, node) {
> > + struct device *dev;
> > + struct opp *opp;
> > + unsigned long freq;
> > +
> > + dev = temp_dev->dev;
>
> if you're doing this assignment here, might as well make 'dev' the
> iterator instead of temp_dev.
temp_dev holds pointer to omap_vdd_dev_list where as dev points to actual
device pointer. Hence this assignment.
>
> This section would benefit with some comments. If I understand the
> code
> correctly, something like:
>
> If a frequency has been requested, use the highest requested frequency.
>
> > + if (!plist_head_empty(&temp_dev->user_list)) {
> > + node = plist_last(&temp_dev->user_list);
> > + freq = node->prio;
>
> otherwise check if device has OPP for this voltage
>
> > + } else {
> > + opp = omap_dvfs_find_voltage(dev, volt);
> > + if (IS_ERR(opp))
> > + continue;
>
> This needs a comment to, but I'm not sure I understand what's going on
> here. What it seems like:
>
> if this device has no OPP for this voltage, just silently move on to the
> next device? doesn't seem quite right, but not sure I fully grok the
> failure modes of omap_dvfs_find_voltage()
Yes, your understanding is right. omap_dvfs_find_volta
RE: [PATCH 04/13] OMAP: Introduce dependent voltage domain support
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Friday, February 04, 2011 9:07 PM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath
> Subject: Re: [PATCH 04/13] OMAP: Introduce dependent voltage domain
> support
>
> Vishwanath BS writes:
>
> > There could be dependencies between various voltage domains for
> > maintaining system performance or hardware limitation reasons
> > like VDD should be at voltage v1 when VDD is at voltage v2.
> > This patch introduce dependent vdd information structures in the
> > voltage layer which can be used to populate these dependencies
> > for a voltage domain. This patch also adds support to scale
> > the dependent vdd and the scalable devices belonging to it
> > during the scaling of a main vdd through omap_voltage_scale.
> >
> > As part of this, some of the voltage layer structure definitions are
> moved from
> > voltage.c to voltage.h as it needs to be used in the dvfs layer for
> dependency
> > voltage handling.
>
> IMO, it would be cleaner to keep this in the voltage layer, and create
> and API for dependencies.
Dependency voltage handling needs some of dvfs layer functions (like
omap_dvfs_add_vdd_user, omap_dvfs_voltage_scale). Given that dvfs layer is
built on top of voltage layer, if these functions need to be implemented
in voltage layer, then voltage layer will end up using dvfs functions
leading to cross dependencies. So I thought keeping this implementation in
dvfs layer makes it more structured.
>
> > Based on original patch from Thara.
> >
> > Signed-off-by: Vishwanath BS
> > Cc: Thara Gopinath
> > ---
> > arch/arm/mach-omap2/dvfs.c| 87
> +
> > arch/arm/mach-omap2/voltage.c | 117
---
> > arch/arm/plat-omap/include/plat/voltage.h | 148
> +
> > 3 files changed, 235 insertions(+), 117 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-
> omap2/dvfs.c
> > index cefc2be..c9d3894 100755
> > --- a/arch/arm/mach-omap2/dvfs.c
> > +++ b/arch/arm/mach-omap2/dvfs.c
> > @@ -85,6 +85,7 @@ struct omap_vdd_dvfs_info {
> > struct mutex scaling_mutex; /* dvfs mutex */
> > struct voltagedomain *voltdm;
> > struct list_head dev_list;
> > + struct device vdd_device;
>
> It's not clear what the usage of this device is for.
>
> It is never initialized, but seems to be used as a dummy device when
> calcluating dependencies. Needs clarification.
This device is used for placing voltage request (omap_dvfs_add_vdd_user)
when dealing with dependent vdds. Eg: while scaling MPU VDD, we also scale
CORE VDD. So while placing voltage request for CORE VDD, this vdd_device
of MPU is used as the requesting device so that this request is stored as
a separate user.
Vishwa
>
> Kevin
--
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 05/13] OMAP: Introduce device scale implementation
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Friday, February 04, 2011 9:35 PM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath
> Subject: Re: [PATCH 05/13] OMAP: Introduce device scale
> implementation
>
> Vishwanath BS writes:
>
> > This patch adds omap_device_scale API which can be used to generic
> > device rate scaling.
>
> I would've expected a new omap_device_* API to be part of the
> omap_device layer, not added here.
Given that this API does not deal with any of the omap_device layer
functions or data structures, I am not sure if it logically belongs to
omap device layer. If you think it should belong to omap_device layer just
because the name starts with omap_device, I would rather rename this API.
>
> > Based on original patch from Thara.
> >
> > Signed-off-by: Vishwanath BS
> > Cc: Thara Gopinath
> > ---
> > arch/arm/mach-omap2/dvfs.c | 116
>
> > arch/arm/plat-omap/include/plat/dvfs.h |7 ++
> > 2 files changed, 123 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-
> omap2/dvfs.c
> > index c9d3894..05a9ce3 100755
> > --- a/arch/arm/mach-omap2/dvfs.c
> > +++ b/arch/arm/mach-omap2/dvfs.c
> > @@ -19,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /**
> > * struct omap_dev_user_list - Structure maitain userlist per device
> > @@ -585,6 +586,121 @@ static int omap_dvfs_voltage_scale(struct
> omap_vdd_dvfs_info *dvfs_info)
> > }
> >
> > /**
> > + * omap_device_scale() - Set a new rate at which the device is to
> operate
> > + * @req_dev: pointer to the device requesting the scaling.
> > + * @target_dev:pointer to the device that is to be scaled
> > + * @rate: the rnew rate for the device.
> > + *
> > + * This API gets the device opp table associated with this device and
> > + * tries putting the device to the requested rate and the voltage
> domain
> > + * associated with the device to the voltage corresponding to the
> > + * requested rate. Since multiple devices can be assocciated with a
> > + * voltage domain this API finds out the possible voltage the
> > + * voltage domain can enter and then decides on the final device
> > + * rate. Return 0 on success else the error value
> > + */
>
> Here would be a good place to describe why both the requesting device
> and the target device need to be tracked.
OK
>
> > +int omap_device_scale(struct device *req_dev, struct device
> *target_dev,
> > + unsigned long rate)
> > +{
> > + struct opp *opp;
> > + unsigned long volt, freq, min_freq, max_freq;
> > + struct omap_vdd_dvfs_info *dvfs_info;
> > + struct platform_device *pdev;
> > + struct omap_device *od;
> > + int ret = 0;
> > +
> > + pdev = container_of(target_dev, struct platform_device, dev);
> > + od = container_of(pdev, struct omap_device, pdev);
> > +
> > + /*
> > +* Figure out if the desired frquency lies between the
> > +* maximum and minimum possible for the particular device
> > +*/
> > + min_freq = 0;
> > + if (IS_ERR(opp_find_freq_ceil(target_dev, &min_freq))) {
> > + dev_err(target_dev, "%s: Unable to find lowest opp\n",
> > + __func__);
> > + return -ENODEV;
> > + }
> > +
> > + max_freq = ULONG_MAX;
> > + if (IS_ERR(opp_find_freq_floor(target_dev, &max_freq))) {
> > + dev_err(target_dev, "%s: Unable to find highest opp\n",
> > + __func__);
> > + return -ENODEV;
> > + }
> > +
> > + if (rate < min_freq)
> > + freq = min_freq;
> > + else if (rate > max_freq)
> > + freq = max_freq;
> > + else
> > + freq = rate;
> > +
>
> OK, frome here on, I would expect the adjusted value 'freq' to be used
> instead of 'rate', but that is not the case below.
>
> > + opp = opp_find_freq_ceil(target_dev, &freq);
> > + if (IS_ERR(opp)) {
> > + dev_err(target_dev, "%s: Unable to find OPP for
> freq%ld\n",
> > + __func__, rate);
> > + return -ENODEV;
> > + }
Freq is appropriate than rate here. Will fix it.
> > +
> > + /* Get the voltage corresponding to the requested frequency */
> > + volt = opp_get_voltage(opp);
> > +
> > + /*
> > +* Call into the voltage layer to get the final voltage possible
> > +* for the voltage domain associated with the device.
> > +*/
>
> This comment doesn't match the following code.
OK. Will fix it. Copy paste error.
>
> > + if (rate) {
>
> Why is rate used here, and not freq?
Freq can never be 0. If somebody wants to remove his DVFS request (he does
not really care about the device frequency), then he can pass rate as 0.
Hence rate is used.
>
> > + dvfs_info = get_dvfs_info(od->hwmods[0]->voltdm);
> > +
> > + ret = omap_dvfs_add_freq_request(dvfs_info, req_dev,
> >
RE: [PATCH 06/13] OMAP: Disable Smartreflex across DVFS
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Friday, February 04, 2011 9:36 PM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath
> Subject: Re: [PATCH 06/13] OMAP: Disable Smartreflex across DVFS
>
> Vishwanath BS writes:
>
> > From: Thara Gopinath
> >
> > This patch disables smartreflex for a particular voltage
> > domain when the the voltage domain and the devices belonging
> > to it is being scaled and re-enables it back once the scaling
> > is done.
>
> Should also describe why.
>
> > Signed-off-by: Thara Gopinath
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/dvfs.c |7 +++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-
> omap2/dvfs.c
> > index 05a9ce3..1e5492c 100755
> > --- a/arch/arm/mach-omap2/dvfs.c
> > +++ b/arch/arm/mach-omap2/dvfs.c
> > @@ -529,6 +529,9 @@ static int omap_dvfs_voltage_scale(struct
> omap_vdd_dvfs_info *dvfs_info)
> >
> > curr_volt = omap_voltage_get_nom_volt(voltdm);
> >
> > + /* Disable smartreflex module across voltage and frequency
> scaling */
>
> comment redundant
>
> > + omap_sr_disable(voltdm);
> > +
> > if (curr_volt == volt) {
> > is_volt_scaled = 1;
> > } else if (curr_volt < volt) {
> > @@ -536,6 +539,7 @@ static int omap_dvfs_voltage_scale(struct
> omap_vdd_dvfs_info *dvfs_info)
> > if (ret) {
> > pr_warning("%s: Unable to scale the %s to %ld
> volt\n",
> > __func__, voltdm->name,
> volt);
> > + omap_sr_enable(voltdm);
>
> Would probably be cleaner to make this error path 'goto' the end where
> the SR enable and mutex_unlock are already being done.
Dependency vdd handing is not required in this case and if I use goto,
then I cannot skip dependency handling since it is done after unlocking
mutex.
>
> > mutex_unlock(&dvfs_info->scaling_mutex);
> > return ret;
> > }
> > @@ -570,6 +574,9 @@ static int omap_dvfs_voltage_scale(struct
> omap_vdd_dvfs_info *dvfs_info)
> > if (!is_volt_scaled && !ret)
> > omap_voltage_scale_vdd(voltdm, volt);
> >
> > + /* Enable Smartreflex module */
>
> comment redundant
ok
Vishwa
>
> > + omap_sr_enable(voltdm);
> > +
> > mutex_unlock(&dvfs_info->scaling_mutex);
> >
> > /* calculate the voltages for dependent vdd's */
>
> Kevin
--
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: [PATCHv2] arm: mach-omap2: smartreflex: fix another memory leak
> -Original Message-
> From: Aaro Koskinen [mailto:aaro.koski...@nokia.com]
> Sent: Monday, February 07, 2011 7:38 PM
> To: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Cc: vishwanath...@ti.com; Aaro Koskinen
> Subject: [PATCHv2] arm: mach-omap2: smartreflex: fix another memory
> leak
>
> Temporary strings with volt_* file names should be released after the
> debugfs entries are created. While at it, also simplify the string
> allocation, and use just snprintf() to create the name.
>
> The patch eliminates kmemleak reports with the following stack trace
> (multiple objects depending on HW):
>
> unreferenced object 0xcedbc5a0 (size 64):
> comm "swapper", pid 1, jiffies 4294929375 (age 423.734s)
> hex dump (first 32 bytes):
> 76 6f 6c 74 5f 39 37 35 30 30 30 00 00 00 00 00 volt_975000.
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> backtrace:
> [] create_object+0x104/0x208
> [] kmem_cache_alloc_trace+0xf0/0x17c
> [] omap_sr_probe+0x314/0x420
> [] platform_drv_probe+0x18/0x1c
> [] driver_probe_device+0xc8/0x188
> [] __driver_attach+0x68/0x8c
> [] bus_for_each_dev+0x44/0x74
> [] bus_add_driver+0xa0/0x228
> [] driver_register+0xa8/0x130
> [] platform_driver_probe+0x18/0x8c
> [] sr_init+0x40/0x74
> [] do_one_initcall+0xc8/0x1a0
> [] kernel_init+0x150/0x218
> [] kernel_thread_exit+0x0/0x8
> [] 0x
>
> Signed-off-by: Aaro Koskinen
> ---
>
> v2: Get rid of kmalloc().
>
> arch/arm/mach-omap2/smartreflex.c | 15 +++
> 1 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
> omap2/smartreflex.c
> index 77ecebf..e54db84 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -927,19 +927,10 @@ static int __init omap_sr_probe(struct
> platform_device *pdev)
> }
>
> for (i = 0; i < sr_info->nvalue_count; i++) {
> - char *name;
> - char volt_name[32];
> -
> - name = kzalloc(NVALUE_NAME_LEN + 1, GFP_KERNEL);
> - if (!name) {
> - dev_err(&pdev->dev, "%s: Unable to allocate
> memory"
> - " for n-value directory name\n",
__func__);
> - return -ENOMEM;
> - }
> + char name[NVALUE_NAME_LEN + 1];
Is there any need to keep this inside the loop? Defining it in the
beginning of function might save a few cpu cycles.
Vishwa
>
> - strcpy(name, "volt_");
> - sprintf(volt_name, "%d", volt_data[i].volt_nominal);
> - strcat(name, volt_name);
> + snprintf(name, sizeof(name), "volt_%d",
> + volt_data[i].volt_nominal);
> (void) debugfs_create_x32(name, S_IRUGO | S_IWUGO,
> nvalue_dir,
> &(sr_info->nvalue_table[i].nvalue));
> }
> --
> 1.5.6.5
--
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 01/13] OMAP: Introduce accessory APIs for DVFS
> -Original Message- > From: Kevin Hilman [mailto:khil...@ti.com] > Sent: Thursday, February 03, 2011 6:37 AM > To: Vishwanath BS > Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath > Subject: Re: [PATCH 01/13] OMAP: Introduce accessory APIs for DVFS > > Vishwanath BS writes: > > > This patch introduces accessory APIs for DVFS. > > Actually, it begins the implementation of a DVFS layer. > > > Data structures added: > > 1. omap_dev_user_list: This structure maintains list of frequency > requests per > >device basis. When a device needs to be scaled to a particular > frequency, > >This list is searched to find the maximum request for a given device. > >If noone has placed any request, device frequency is obtained from > device > >opp table. > > 2. omap_vdd_dev_list: This strcucture stores device list per vdd basis. > >Whenever a device is registered with a vdd, it is added to this list. > > 3. omap_vdd_user_list: User list of devices associated with each > voltage domain > >instance. The user list is implemented using plist structure with > priority > >node populated with the voltage values. > > 4. omap_vdd_dvfs_info: This structure is used to abstract DVFS > related > >information per VDD basis. It holds pointer to corresponding vdd's > >voltagedomain instance and pointer to user list. > > The terms "user" and dev/device are rather overloaded here and > elsewhere > in the code, and makes for rather difficult reading. > > I have an idea (or two) to rework these data structures and how they're > stored/connected, but I need to think on it a little more. More on that > tomorrow... > > > Following APIs have been added to operate on above data structures: > > 1. omap_dvfs_add_vdd_user - API to add a user into > omap_vdd_user_list > > 2. omap_vdd_user_list - API to remove a user from > omap_vdd_user_list > > huh? cut and paste error? I think this was supposed to be > _remove_vdd_user() ? oops..sorry for the typo. Will fix it. > > > 3. omap_dvfs_register_device - API to register a device with vdd > > 4. omap_dvfs_add_freq_request - API to add a frequency request into > >omap_dev_user_list > > 5. omap_dvfs_remove_freq_request - API to remove a frequency > request from > >omap_dev_user_list > > 6. omap_dvfs_find_voltage - API to find the opp corresponding to > given voltage > > I think function naming needs rework for consistency. For example, to > request a frequency you call _add_freq_request(), but to add a voltage > you call _add_vdd_user(), not very reader friendly > > How about simply: > > omap_dvfs_request_freq() > omap_dvfs_request_volt() > > with remove equivalents. > > Actually, looking more at the functions in this patch, the frequency and > voltage functions here are basically identical. There really isn't any > good reason to have separate functions for frequency and voltage. How > about: > > omap_dvfs_add_request(dvfs_info, class, req_dev, target_dev); > omap_dvfs_remove_request(dvfs_info, class, req_dev, target_dev); > > where class = OMAP_DVFS_FREQ | OMAP_DVFS_VOLT. This way, based > on the > class, you can add the requests to the separate lists, but bulk > of the function is the same. I am not sure if this is a good idea to club them into the same function. If you look at those functions, common thing done by them is adding to the list. But actually the way the list is found and the actual list being added are completely different. Voltage request is added to the user list per VDD. Frequency request is added to user list per device and we have device list per vdd. That is the reason why target_dev is needed while adding frequency request and is not needed while adding voltage request. I feel clubbing these 2 functions will make function bulky and more unreadable. I can rename these 2 functions like the way you suggested. > > > > > DVFS layer is initialized and basic data structures are allocated and > > initialized as part of this. > > > > This patch is based on Thara's previous DVFS implementation, but with > major > > rework. > > > > Minor comment on acronyms. In the comments throughout, please > capitalize acronyms like DVFS, VDD, etc. Currently, it is mixed between > upper and lower-case. OK. Will fix it in next version. > > > Signed-off-by: Vishwanath BS > > Cc: Thara Gopinath > > --- > > arch/arm/mach-omap2/Makefile |2 +- > > arch/arm/mach-omap2/dvfs.c | 456 > > > arch/arm/plat-omap/include/plat/dvfs.h | 27 ++ > > arch/arm/plat-omap/omap_device.c |9 + > > 4 files changed, 493 insertions(+), 1 deletions(-) > > create mode 100644 arch/arm/mach-omap2/dvfs.c > > create mode 100644 arch/arm/plat-omap/include/plat/dvfs.h > > > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach- > omap2/Makefile > > index 4ab82f6..bb2e2bc 100644 > > --- a/arch/arm/mach-omap2/Makefile > > +++ b/arch/arm/mach-omap2/Makefile > > @@ -61,7
RE: [PATCH 03/13] OMAP: Implement Basic DVFS
> -Original Message- > From: Kevin Hilman [mailto:khil...@ti.com] > Sent: Wednesday, February 09, 2011 9:30 PM > To: Vishwanath Sripathy > Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath > Subject: Re: [PATCH 03/13] OMAP: Implement Basic DVFS > > Vishwanath Sripathy writes: > > >> This needs a comment to, but I'm not sure I understand what's going > on > >> here. What it seems like: > >> > >> if this device has no OPP for this voltage, just silently move on to the > >> next device? doesn't seem quite right, but not sure I fully grok the > >> failure modes of omap_dvfs_find_voltage() > > > > Yes, your understanding is right. omap_dvfs_find_voltage will return > error > > if the device does not have an OPP table. > > Typically devices should not register with a vdd (using > > omap_dvfs_register_device) if it has no OPP table associated with it. > So > > ideally we should not hit this error case. But only exception so far is SR > > driver. SR hwmod has vdd_name field set so as to get voltagedomain > > pointers. But SR does not have any opp table. So there is no harm in > > ignoring the error and moving to next device. > > And what happens when other devices add voltage domains but don't > have > OPP tables? If someone does not have a OPP table, that means it's not a scalable device, so there is no need to scale that device. Vishwa > > The point is that this error handling is 1) difficult to understand upon > first (or fifth) read and 2) very fragile with other changes. > > Kevin -- 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 04/13] OMAP: Introduce dependent voltage domain support
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Thursday, February 10, 2011 10:07 PM
> To: Vishwanath Sripathy
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath
> Subject: Re: [PATCH 04/13] OMAP: Introduce dependent voltage domain
> support
>
> Vishwanath Sripathy writes:
>
> [...]
>
> >> > diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-
> >> omap2/dvfs.c
> >> > index cefc2be..c9d3894 100755
> >> > --- a/arch/arm/mach-omap2/dvfs.c
> >> > +++ b/arch/arm/mach-omap2/dvfs.c
> >> > @@ -85,6 +85,7 @@ struct omap_vdd_dvfs_info {
> >> > struct mutex scaling_mutex; /* dvfs mutex */
> >> > struct voltagedomain *voltdm;
> >> > struct list_head dev_list;
> >> > +struct device vdd_device;
> >>
> >> It's not clear what the usage of this device is for.
> >>
> >> It is never initialized, but seems to be used as a dummy device when
> >> calcluating dependencies. Needs clarification.
> >
> > This device is used for placing voltage request
> (omap_dvfs_add_vdd_user)
> > when dealing with dependent vdds. Eg: while scaling MPU VDD, we
> also scale
> > CORE VDD. So while placing voltage request for CORE VDD, this
> vdd_device
> > of MPU is used as the requesting device so that this request is stored
> as
> > a separate user.
>
> I was able to follow how it was used, and why. But it is still not
> clear to the reader.
>
> First, the device is never initialized, so it's essentially a dummy
> device that remains initialized by default to all zeros. So, any
> attempt to use any device APIs (e.g. dev_name, etc.) on this will not
> behave as expected.
>
> Second, the reason for this device and the need for the request to be
> stored as a separate user are not clear in the code and don't exist in
> the comments.
OK. I will add more comments to make these details more explicit.
Vishwa
>
> Kevin
>
>
>
>
--
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 08/13] OMAP3: cpufreq driver changes for DVFS support
> -Original Message-
> From: Kahn, Gery [mailto:ge...@ti.com]
> Sent: Monday, February 14, 2011 3:04 PM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Santosh Shilimkar
> Subject: Re: [PATCH 08/13] OMAP3: cpufreq driver changes for DVFS
> support
>
> Dear Vishwanath,
>
> On Fri, Jan 21, 2011 at 16:01, Vishwanath BS
> wrote:
> > Changes in the omap cpufreq driver for DVFS support.
> >
> > Signed-off-by: Vishwanath BS
> > Cc: Santosh Shilimkar
> > ---
> > arch/arm/plat-omap/cpu-omap.c | 35
> ---
> > 1 files changed, 32 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-
> omap/cpu-omap.c
> > index 1c1b80b..d965220 100644
> > --- a/arch/arm/plat-omap/cpu-omap.c
> > +++ b/arch/arm/plat-omap/cpu-omap.c
> > @@ -30,10 +30,12 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #if defined(CONFIG_ARCH_OMAP3) &&
> !defined(CONFIG_OMAP_PM_NONE)
> > #include
> > #include
> > +#include
> > #endif
> >
> > #define VERY_HI_RATE 9
> > @@ -85,11 +87,11 @@ static int omap_target(struct cpufreq_policy
> *policy,
> > unsigned int target_freq,
> > unsigned int relation)
> > {
> > -#ifdef CONFIG_ARCH_OMAP1
> > struct cpufreq_freqs freqs;
> > -#endif
> > #if defined(CONFIG_ARCH_OMAP3) &&
> !defined(CONFIG_OMAP_PM_NONE)
> > unsigned long freq;
> > + int i;
> > + struct cpufreq_freqs freqs_notify;
> > struct device *mpu_dev = omap2_get_mpuss_device();
> > #endif
> > int ret = 0;
> > @@ -116,9 +118,36 @@ static int omap_target(struct cpufreq_policy
> *policy,
> > ret = clk_set_rate(mpu_clk, freqs.new * 1000);
> > cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > #elif defined(CONFIG_ARCH_OMAP3) &&
> !defined(CONFIG_OMAP_PM_NONE)
> > + freqs.old = omap_getspeed(policy->cpu);;
> > + freqs_notify.new = clk_round_rate(mpu_clk, target_freq *
> 1000) / 1000;
> > + freqs.cpu = policy->cpu;
> > +
> > + if (freqs.old == freqs.new)
> > + return ret;
> > +
> > + /* pre notifiers */
> > + for_each_cpu(i, policy->cpus) {
> > + freqs.cpu = i;
> > + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > + }
> > +
> > + /* scale the frequency */
> > freq = target_freq * 1000;
> > if (opp_find_freq_ceil(mpu_dev, &freq))
> > - omap_pm_cpu_set_freq(freq);
> > + omap_device_scale(mpu_dev, mpu_dev, freq);
> > +
> > + /* Update loops per jiffy */
> > + freqs.new = omap_getspeed(policy->cpu);
> > + for_each_cpu(i, policy->cpus)
> > + per_cpu(cpu_data, i).loops_per_jiffy =
> > + cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
> > + freqs.old, freqs.new);
> > +
> > + /* post notifiers */
> > + for_each_cpu(i, policy->cpus) {
> > + freqs.cpu = i;
> > + cpufreq_notify_transition(&freqs,
> CPUFREQ_POSTCHANGE);
> > + }
> > #endif
> > return ret;
> > }
> > --
> > 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
> >
>
> I took those patches and applied to my .38-rc4 with help from Nishanth
> Menon.
>
> There is problem appeared during compilation:
>
> arch/arm/plat-omap/cpu-omap.c:142: error: 'struct cpuinfo_arm' has no
> member named 'loops_per_jiffy'
>
> My kernel is for Zoom3 board (OMAP3630-GP rev 2, CPU-OPP2 L3-
> 200MHz)
> Looking at the source, arch/arm/include/asm/cpu.h
> loops_per_jiffy is under CONFIG_SMP and since the omap2plus_defconfig
> builds for OMAP4 as well by default, I am guessing this bug was not
> immediately visible...
>
> Is there solution for the issue?
Yes this is an issue if CONFIG_SMP is disabled. We probably will need to
put this code under #ifdef CONFIG_SMP till lpj is handled for SMP in
generic cpufreq code itself .
Vishwa
>
> Regards,
> Gery
--
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 08/13] OMAP3: cpufreq driver changes for DVFS support
> -Original Message- > From: Menon, Nishanth [mailto:n...@ti.com] > Sent: Monday, February 14, 2011 6:33 PM > To: Vishwanath Sripathy > Cc: Gery Kahn; linux-omap@vger.kernel.org; patc...@linaro.org; > Santosh Shilimkar > Subject: Re: [PATCH 08/13] OMAP3: cpufreq driver changes for DVFS > support > > On Mon, Feb 14, 2011 at 18:19, Vishwanath Sripathy > wrote: > > >> Is there solution for the issue? > > Yes this is an issue if CONFIG_SMP is disabled. We probably will need > to > > put this code under #ifdef CONFIG_SMP till lpj is handled for SMP in > > generic cpufreq code itself . > > > Apologies, I am not clear, but how'd we handle the non smp case here? For non SMP case, lpj is updated in common cpufreq code (in adjust_jiffies function). Vishwa > > Regards, > Nishanth Menon -- 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/2] OMAP: PM: implement devices wakeup latency constraints APIs
> -Original Message-
> From: jean.pi...@newoldbits.com [mailto:jean.pi...@newoldbits.com]
> Sent: Friday, February 11, 2011 12:53 AM
> To: khil...@ti.com; p...@pwsan.com; Vibhore Vardhan; Santosh
> Shilimkar; Vishwanath BS; rna...@ti.com
> Cc: linux-omap@vger.kernel.org; Jean Pihet; Vibhore Vardhan
> Subject: [PATCH 2/2] OMAP: PM: implement devices wakeup latency
> constraints APIs
>
> From: Jean Pihet
>
> Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
> creating similar APIs at the omap_device and omap_hwmod levels. The
> omap_hwmod level call is the layer with access to the powerdomain
> core, so it is the place where the powerdomain is queried to set and
> release the constraints.
>
> NOTE: only works for devices which have been converted to use
> omap_device/omap_hwmod.
>
> Longer term, we could possibly remove this API from the OMAP PM layer,
> and instead directly use the omap_device level API.
>
> Based on Vibhore's original patch , adapted to omap_device and
> omap_hwmod frameworks.
>
> Signed-off-by: Jean Pihet
> Cc: Vibhore Vardhan
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 62 +-
> arch/arm/mach-omap2/powerdomain.c | 176
> -
> arch/arm/mach-omap2/powerdomain.h | 31 +
> arch/arm/mach-omap2/powerdomains3xxx_data.c | 60
> +
> arch/arm/plat-omap/include/plat/omap_device.h |2 +
> arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
> arch/arm/plat-omap/omap-pm-constraints.c | 101 ++-
> arch/arm/plat-omap/omap_device.c | 28
> 8 files changed, 399 insertions(+), 63 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
> omap2/omap_hwmod.c
> index e282e35..0dc096f 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -142,6 +142,7 @@
> #include "powerdomain.h"
> #include
> #include
> +#include
> #include
>
> #include "cm2xxx_3xxx.h"
> @@ -2198,10 +2199,69 @@ ohsps_unlock:
> }
>
> /**
> + * omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up
> constraint
> + * @oh: struct omap_hwmod *
> + * @req_oh: struct omap_hwmod *
Need to explain what this parameters mean.
> + * @t: wakeup latency constraint (us). -1 removes the existing
> constraint
> + *
> + * Query the powerdomain of @oh to set/release the wake-up
> constraint
> + *
> + * Returns -EINVAL if @oh or @req_oh have no power domain, or the
> return
> + * code from the pwrdm function
> (pwrdm_wakeuplat_set/release_constraint)
> + * of the powerdomain assocated with @oh.
> + */
> +int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod
> *req_oh,
> + struct omap_hwmod *oh, long t)
> +{
> + struct device *req_dev;
> + struct platform_device *pdev;
> + struct powerdomain *pwrdm;
> + int ret = 0;
> +
> + pwrdm = omap_hwmod_get_pwrdm(oh);
> +
> + /* Catch devices with undefined powerdomains */
> + if (!pwrdm) {
> + pr_err("omap_hwmod: Error: could not find parent "
> + "powerdomain for %s\n", oh->name);
> + return -EINVAL;
> + }
> +
> + pdev = &(req_oh->od->pdev);
> + if (pdev == NULL) {
> + pr_err("omap_hwmod: Error: pdev not found for oh %s\n",
> +oh->name);
> + return -EINVAL;
> + }
> +
> + req_dev = &(pdev->dev);
> + if (req_dev == NULL) {
> + pr_err("omap_hwmod: Error: device not found for oh
> %s\n",
> +oh->name);
> + return -EINVAL;
> + }
If I understand correctly, req_dev is used for keeping track of different
requests. If so, why can't you directly pass req_dev as an input param
instead of deriving it from pdev.
> +
> + /* Call set/release_constraint for the given pwrdm */
> + if (t == -1) {
> + pr_debug("omap_hwmod: remove max device latency
> constraint: "
> + "oh %s, pwrdm %s, req by oh %s\n",
> + oh->name, pwrdm->name, req_oh->name);
> + ret = pwrdm_wakeuplat_release_constraint(pwrdm,
> req_dev);
> + } else {
> + pr_debug("omap_hwmod: add max device latency
> constraint: "
> + "oh %s, t = %ld usec, pwrdm %s, req by oh
> %s\n",
> + oh->name, t, pwrdm->name, req_oh->name);
> + ret = pwrdm_wakeuplat_set_constraint(pwrdm, req_dev,
> t);
> + }
> +
> + return 0;
> +}
> +
> +/**
> * omap_hwmod_get_context_loss_count - get lost context count
> * @oh: struct omap_hwmod *
> *
> - * Query the powerdomain of of @oh to get the context loss
> + * Query the powerdomain of @oh to get the context loss
> * count for this device.
> *
> * Returns the context loss count of the powerdomain assocated with
> @oh
> diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-
> omap2/powerdomain.c
> index eaed0df..3ed3bea 100644
> --- a/a
RE: [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
> -Original Message-
> From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
> kernel-boun...@lists.infradead.org] On Behalf Of Jarkko Nikula
> Sent: Tuesday, February 15, 2011 8:47 PM
> To: Shweta Gulati
> Cc: Nishanth Menon; Thara Gopinath; linux-omap@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on
> TWL
>
> On Tue, 15 Feb 2011 13:28:58 +0530
> Shweta Gulati wrote:
>
> > This patch is based on LO PM Branch and Smartreflex has been
> > tested on OMAP3430 SDP, OMAP3630 SDP and boot tested on
> > OMAP2430 SDP.
> >
> I saw this was working on N900 (kind of special instrumentation
> setup) after enabling /sys/kernel/debug/voltage/[vdd_core |
> vdd_mpu]/smartreflex/autocomp. Few comments below.
>
> > @@ -269,6 +276,18 @@ int __init omap3_twl_init(void)
> > omap3_core_volt_info.vp_vddmax =
> OMAP3630_VP2_VLIMITTO_VDDMAX;
> > }
> ...
> > + if (!twl_sr_enable_autoinit)
> > + omap3_twl_set_sr_bit(true);
> ...
> > +int __init omap3_twl_set_sr_bit(bool enable)
> > +{
> > + u8 temp;
> > + int ret;
> > + if (twl_sr_enable_autoinit)
> > + pr_warning("%s: unexpected multiple calls\n", __func__);
> > +
> > + ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &temp,
> > + TWL4030_DCDC_GLOBAL_CFG);
> > + if (ret)
> > + goto err;
> > +
> > + if (enable)
> > + temp |= SMARTREFLEX_ENABLE;
> > + else
> > + temp &= ~SMARTREFLEX_ENABLE;
> > +
> > + ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
> > + TWL4030_DCDC_GLOBAL_CFG);
>
> Would it make more sense to set only the flag here and do the register
> writes when omap3_twl_init is executing? Then it's not so strict when
> the board code calls this function.
What if board code calls this function after twl_init is executed? Then
you will not clear the bit right?
Intention of this function is to make sure the bit is set/cleared when it
is called.
vishwa
>
> > + if (!ret) {
> > + twl_sr_enable_autoinit = true;
> > + return 0;
>
> Should this be twl_sr_enable_autoinit = enable (if going to do
> register write here)?
>
> --
> Jarkko
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/2] OMAP: PM: implement devices wakeup latency constraints APIs
> -Original Message-
> From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
> Sent: Tuesday, February 15, 2011 7:22 PM
> To: Vishwanath Sripathy
> Cc: Kevin Hilman; p...@pwsan.com; Vibhore Vardhan; Santosh
> Shilimkar; Rajendra Nayak; linux-omap@vger.kernel.org; Jean Pihet-XID
> Subject: Re: [PATCH 2/2] OMAP: PM: implement devices wakeup latency
> constraints APIs
>
> Hi Vishwa,
>
> On Tue, Feb 15, 2011 at 10:35 AM, Vishwanath Sripathy
> wrote:
> >> -Original Message-
> >> From: jean.pi...@newoldbits.com
> [mailto:jean.pi...@newoldbits.com]
> >> Sent: Friday, February 11, 2011 12:53 AM
> >> To: khil...@ti.com; p...@pwsan.com; Vibhore Vardhan; Santosh
> >> Shilimkar; Vishwanath BS; rna...@ti.com
> >> Cc: linux-omap@vger.kernel.org; Jean Pihet; Vibhore Vardhan
> >> Subject: [PATCH 2/2] OMAP: PM: implement devices wakeup latency
> >> constraints APIs
> >>
> >> From: Jean Pihet
> >>
> >> Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API
> by
> >> creating similar APIs at the omap_device and omap_hwmod levels.
> The
> >> omap_hwmod level call is the layer with access to the powerdomain
> >> core, so it is the place where the powerdomain is queried to set and
> >> release the constraints.
> >>
> >> NOTE: only works for devices which have been converted to use
> >> omap_device/omap_hwmod.
> >>
> >> Longer term, we could possibly remove this API from the OMAP PM
> layer,
> >> and instead directly use the omap_device level API.
> >>
> >> Based on Vibhore's original patch , adapted to omap_device and
> >> omap_hwmod frameworks.
> >>
> >> Signed-off-by: Jean Pihet
> >> Cc: Vibhore Vardhan
> >> ---
> >> arch/arm/mach-omap2/omap_hwmod.c | 62
> +-
> >> arch/arm/mach-omap2/powerdomain.c | 176
> >> -
> >> arch/arm/mach-omap2/powerdomain.h | 31 +
> >> arch/arm/mach-omap2/powerdomains3xxx_data.c | 60
> >> +
> >> arch/arm/plat-omap/include/plat/omap_device.h | 2 +
> >> arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
> >> arch/arm/plat-omap/omap-pm-constraints.c | 101 ++
> -
> >> arch/arm/plat-omap/omap_device.c | 28
> >> 8 files changed, 399 insertions(+), 63 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-
> >> omap2/omap_hwmod.c
> >> index e282e35..0dc096f 100644
> >> --- a/arch/arm/mach-omap2/omap_hwmod.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> >> @@ -142,6 +142,7 @@
> >> #include "powerdomain.h"
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> #include "cm2xxx_3xxx.h"
> >> @@ -2198,10 +2199,69 @@ ohsps_unlock:
> >> }
> >>
> >> /**
> >> + * omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up
> >> constraint
> >> + * @oh: struct omap_hwmod *
> >> + * @req_oh: struct omap_hwmod *
> > Need to explain what this parameters mean.
> Ok, will add a description here. Basically oh corresponds to the
> device (and so the power domain) to set a constraint on and req_oh is
> the constraint requester. oh is used to determine which power domain
> to set a constraint on, req_oh is used to record the requester for
> later update or removal of a constraint.
>
> >> + * @t: wakeup latency constraint (us). -1 removes the existing
> >> constraint
> >> + *
> >> + * Query the powerdomain of @oh to set/release the wake-up
> >> constraint
> >> + *
> >> + * Returns -EINVAL if @oh or @req_oh have no power domain, or
> the
> >> return
> >> + * code from the pwrdm function
> >> (pwrdm_wakeuplat_set/release_constraint)
> >> + * of the powerdomain assocated with @oh.
> >> + */
> >> +int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod
> >> *req_oh,
> >> + struct omap_hwmod *oh, long t)
> >> +{
> >> + struct device *req_dev;
> >> + struct platform_device *pdev;
> >> + struct powerdomain *pwrdm;
> >> + int ret = 0;
> >> +
> >> + pwrdm = omap_hwmod_get_pwrdm(oh);
> >> +
> >> + /* Catch devices with undefined powerdomains */
> >> + if (!pwrdm) {
> >>
RE: [PATCH 02/19] omap3630: hwmod: sr: enable for higher ES
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Saturday, February 19, 2011 5:32 PM
> To: linux-omap
> Cc: Tony Lindgren; Kevin Hilman; Nishanth Menon
> Subject: [PATCH 02/19] omap3630: hwmod: sr: enable for higher ES
>
> Enable hwmod entries for OMAP3630 for higher ES revisions as
> well. This is to ensure that SR can be used in all revisions of
> OMAP3630 as of this posting.
>
> Signed-off-by: Nishanth Menon
> ---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index ea1f49a..bbcbea6 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -1318,7 +1318,9 @@ static struct omap_hwmod
> omap36xx_sr1_hwmod = {
> },
> .slaves = omap3_sr1_slaves,
> .slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
> - .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1|
> + CHIP_IS_OMAP3630ES1_1 |
> + CHIP_IS_OMAP3630ES1_2),
What's the need of this?
Here is the code snippet from id.c
-snip-
case 0xb891:
/* Handle 36xx devices */
omap_chip.oc |= CHIP_IS_OMAP3630ES1;
switch(rev) {
case 0: /* Take care of early samples */
omap_revision = OMAP3630_REV_ES1_0;
break;
case 1:
omap_revision = OMAP3630_REV_ES1_1;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_1;
break;
case 2:
default:
omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
}
So it's clear that omap_chip.oc will have CHIP_IS_OMAP3630ES1 anyway on
all ES versions.
Vishwa
> .mpu_irqs = omap3_smartreflex_mpu_irqs,
> .mpu_irqs_cnt =
> ARRAY_SIZE(omap3_smartreflex_mpu_irqs),
> };
> @@ -1368,7 +1370,9 @@ static struct omap_hwmod
> omap36xx_sr2_hwmod = {
> },
> .slaves = omap3_sr2_slaves,
> .slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
> - .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1|
> + CHIP_IS_OMAP3630ES1_1 |
> + CHIP_IS_OMAP3630ES1_2),
> .mpu_irqs = omap3_smartreflex_core_irqs,
> .mpu_irqs_cnt =
> ARRAY_SIZE(omap3_smartreflex_core_irqs),
> };
> --
> 1.7.1
>
> --
> 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 03/19] omap3+: voltage: remove initial voltage
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Nishanth Menon > Sent: Saturday, February 19, 2011 5:32 PM > To: linux-omap > Cc: Tony Lindgren; Kevin Hilman; Nishanth Menon > Subject: [PATCH 03/19] omap3+: voltage: remove initial voltage > > omap2_set_init_voltage should setup the curr_volt based on which OPP > the system is functioning at. Blindly setting a 1.2v setting in the > initial structure may not even match the default voltages stored in > the voltage table which are supported for the domain. > > For example, OMAP3430 core domain does not use 1.2v and ends up > generating a warning on the first transition. > > Signed-off-by: Nishanth Menon > --- > arch/arm/mach-omap2/voltage.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach- > omap2/voltage.c > index 12be525..280ee12 100644 > --- a/arch/arm/mach-omap2/voltage.c > +++ b/arch/arm/mach-omap2/voltage.c > @@ -863,7 +863,6 @@ static int __init > omap3_vdd_data_configure(struct omap_vdd_info *vdd) > sys_clk_speed /= 1000; > > /* Generic voltage parameters */ > - vdd->curr_volt = 120; > vdd->ocp_mod = OCP_MOD; > vdd->prm_irqst_reg = OMAP3_PRM_IRQSTATUS_MPU_OFFSET; > vdd->read_reg = omap3_voltage_read_reg; > @@ -1054,7 +1053,6 @@ static int __init > omap4_vdd_data_configure(struct omap_vdd_info *vdd) > sys_clk_speed /= 1000; > > /* Generic voltage parameters */ > - vdd->curr_volt = 120; Where do you update this parameter upon initialization? Shouldn't you read the VP register and find the actual current voltage and update this param? Vishwa > vdd->ocp_mod = OMAP4430_PRM_OCP_SOCKET_INST; > vdd->read_reg = omap4_voltage_read_reg; > vdd->write_reg = omap4_voltage_write_reg; > -- > 1.7.1 > > -- > 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 15/19] omap3+: sr: introduce notifier_control
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Saturday, February 19, 2011 5:32 PM
> To: linux-omap
> Cc: Tony Lindgren; Kevin Hilman; Nishanth Menon
> Subject: [PATCH 15/19] omap3+: sr: introduce notifier_control
>
> We need some mechanism from class drivers to control when notifiers
> should be triggered and when not, currently we have none, which makes
> Class driver usage of the interrupt events almost impossible.
> Introduce an smartreflex driver api for doing the same.
>
> Signed-off-by: Nishanth Menon
> ---
> arch/arm/mach-omap2/smartreflex.c | 57
> +
> arch/arm/plat-omap/include/plat/smartreflex.h |8
> 2 files changed, 65 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
> omap2/smartreflex.c
> index 165f6f3..ad23b8d 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -704,6 +704,63 @@ void sr_disable(struct voltagedomain *voltdm)
> }
>
> /**
> + * sr_notifier_control() - control the notifier mechanism
> + * @voltdm: VDD pointer to which the SR module to be configured
> belongs to.
> + * @enable: true to enable notifiers and false to disable the same
> + *
> + * SR modules allow an MCU interrupt mechanism that vary based on
> the IP
> + * revision, we allow the system to generate interrupt if the class
driver
> + * has capability to handle the same. it is upto the class driver to
> ensure
> + * the proper sequencing and handling for a clean implementation.
> returns
> + * 0 if all goes fine, else returns failure results
> + */
> +int sr_notifier_control(struct voltagedomain *voltdm, bool enable)
> +{
> + struct omap_sr *sr = _sr_lookup(voltdm);
> + u32 value = 0;
> + if (IS_ERR_OR_NULL(sr)) {
> + pr_warning("%s: sr corresponding to domain not found\n",
> + __func__);
> + return -EINVAL;
> + }
> + if (!sr->autocomp_active)
> + return -EINVAL;
Why you do you return here? Class driver should still be able to place
it's request even if sr is disabled though it will be effective only after
sr is enabled.
Vishwa
> +
> + /* if I could never register an isr, why bother?? */
> + if (!(sr_class && sr_class->notify && sr_class->notify_flags &&
> + sr->irq)) {
> + dev_warn(&sr->pdev->dev,
> + "%s: unable to setup irq without handling
> mechanism\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> + switch (sr->ip_type) {
> + case SR_TYPE_V1:
> + value = notifier_to_irqen_v1(sr_class->notify_flags);
> + sr_modify_reg(sr, ERRCONFIG_V1, value,
> + (enable) ? value : 0);
> + break;
> + case SR_TYPE_V2:
> + value = notifier_to_irqen_v2(sr_class->notify_flags);
> + sr_write_reg(sr, (enable) ? IRQENABLE_SET :
> IRQENABLE_CLR,
> + value);
> + break;
> + default:
> + dev_warn(&sr->pdev->dev, "%s: unknown type of
> sr??\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> + if (enable)
> + enable_irq(sr->irq);
> + else
> + disable_irq_nosync(sr->irq);
> +
> + return 0;
> +}
> +
> +/**
> * sr_register_class() - API to register a smartreflex class
parameters.
> * @class_data: The structure containing various sr class specific
> data.
> *
> diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
> b/arch/arm/plat-omap/include/plat/smartreflex.h
> index ff07d1e..d420f44 100644
> --- a/arch/arm/plat-omap/include/plat/smartreflex.h
> +++ b/arch/arm/plat-omap/include/plat/smartreflex.h
> @@ -242,6 +242,7 @@ void omap_sr_register_pmic(struct
> omap_sr_pmic_data *pmic_data);
> /* Smartreflex driver hooks to be called from Smartreflex class driver
*/
> int sr_enable(struct voltagedomain *voltdm, unsigned long volt);
> void sr_disable(struct voltagedomain *voltdm);
> +int sr_notifier_control(struct voltagedomain *voltdm, bool enable);
> int sr_configure_errgen(struct voltagedomain *voltdm);
> int sr_configure_minmax(struct voltagedomain *voltdm);
>
> @@ -250,6 +251,13 @@ int sr_register_class(struct
> omap_sr_class_data *class_data);
> #else
> static inline void omap_sr_enable(struct voltagedomain *voltdm) {}
> static inline void omap_sr_disable(struct voltagedomain *voltdm) {}
> +
> +static inline int sr_notifier_control(struct voltagedomain *voltdm,
> + bool enable)
> +{
> + return -EINVAL;
> +}
> +
> static inline void omap_sr_disable_reset_volt(
> struct voltagedomain *voltdm) {}
> static inline void omap_sr_register_pmic(
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>
RE: [PATCH 15/19] omap3+: sr: introduce notifier_control
> -Original Message-
> From: Nishanth Menon [mailto:n...@ti.com]
> Sent: Sunday, February 20, 2011 10:20 AM
> To: Vishwanath Sripathy
> Cc: linux-omap; Tony Lindgren; Kevin Hilman
> Subject: Re: [PATCH 15/19] omap3+: sr: introduce notifier_control
>
> Vishwanath Sripathy wrote, on 02/19/2011 07:10 PM:
>
> >> +int sr_notifier_control(struct voltagedomain *voltdm, bool enable)
> >> +{
> >> + struct omap_sr *sr = _sr_lookup(voltdm);
> >> + u32 value = 0;
> >> + if (IS_ERR_OR_NULL(sr)) {
> >> + pr_warning("%s: sr corresponding to domain not found\n",
> >> + __func__);
> >> + return -EINVAL;
> >> + }
> >> + if (!sr->autocomp_active)
> >> + return -EINVAL;
> > Why you do you return here? Class driver should still be able to place
> > it's request even if sr is disabled though it will be effective only
after
> > sr is enabled.
>
> my intents were as following: which useful event would come without SR
> avs being enabled? what kind of event do you expect with the AVS
> disabled which is useful for class driver, whose clase init alone was
> called and not class enable?
The point I am making here is, why should SR class driver be prevented to
register for some events when SR is disabled? If it is prevented here,
then it needs to keep track that the request is denied and needs to make
the request again when SR is enabled later.
Vishwa
>
> --
> Regards,
> Nishanth Menon
--
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 03/19] omap3+: voltage: remove initial voltage
> -Original Message- > From: Nishanth Menon [mailto:n...@ti.com] > Sent: Sunday, February 20, 2011 10:42 AM > To: Vishwanath Sripathy > Cc: linux-omap; Tony Lindgren; Kevin Hilman > Subject: Re: [PATCH 03/19] omap3+: voltage: remove initial voltage > > Vishwanath Sripathy wrote, on 02/19/2011 06:54 PM: > [..] > >> omap2_set_init_voltage should setup the curr_volt based on which > OPP > >> the system is functioning at. Blindly setting a 1.2v setting in the > >> initial structure may not even match the default voltages stored in > >> the voltage table which are supported for the domain. > >> > >> For example, OMAP3430 core domain does not use 1.2v and ends up > >> generating a warning on the first transition. > >> > [..] > >> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach- > >> omap2/voltage.c > >> index 12be525..280ee12 100644 > >> --- a/arch/arm/mach-omap2/voltage.c > >> +++ b/arch/arm/mach-omap2/voltage.c > [..] > >>/* Generic voltage parameters */ > >> - vdd->curr_volt = 120; > > Where do you update this parameter upon initialization? Shouldn't you > read > > the VP register and find the actual current voltage and update this > param? > > The sequence is as follows: > a) omapx_vdd_data configure is called as part of sr init sequence. > And the curr_volt with this patch is not updated at this stage. > b) somewhere down in the boot sequence, pm.c's > omap2_set_init_voltage > starts up. This looks up the current clk frequency from clock layer of > the parent device for the domain, picks up the nominal voltages stored > in the opp layer, then does a omap_voltage_scale_vdd to that voltage. In > omap_voltage_scale_vdd, The current voltage is merely picked off the vp > (in _pre_volt_scale). the last step it does is to setup vdd->curr_volt. > This can then be used by dvfs layer etc to make appropriate decisions. > > So, No, I dont think I need to update it here, it should happen as part > of the pm init sequence. > > Could you explain what problem do you foresee by doing this? What if omap_voltage_scale_vdd fails when called from omap2_set_init_voltage? Or omap2_set_init_voltage returns error even before calling omap_voltage_scale_vdd because it could not find the matching voltage for the frequency set by bootloader? Your assumption that curr_volt is always set by omap2_set_init_voltage need not be true always. Vishwa > > -- > Regards, > Nishanth Menon -- 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 03/19] omap3+: voltage: remove initial voltage
> -Original Message- > From: Menon, Nishanth [mailto:n...@ti.com] > Sent: Wednesday, February 23, 2011 1:48 PM > To: Vishwanath Sripathy > Cc: linux-omap; Tony Lindgren; Kevin Hilman > Subject: Re: [PATCH 03/19] omap3+: voltage: remove initial voltage > > Wed, Feb 23, 2011 at 12:24, Vishwanath Sripathy > wrote: > >> -Original Message- > >> From: Nishanth Menon [mailto:n...@ti.com] > >> Sent: Sunday, February 20, 2011 10:42 AM > >> To: Vishwanath Sripathy > >> Cc: linux-omap; Tony Lindgren; Kevin Hilman > >> Subject: Re: [PATCH 03/19] omap3+: voltage: remove initial voltage > >> > >> Vishwanath Sripathy wrote, on 02/19/2011 06:54 PM: > >> [..] > >> >> omap2_set_init_voltage should setup the curr_volt based on > which > >> OPP > >> >> the system is functioning at. Blindly setting a 1.2v setting in the > >> >> initial structure may not even match the default voltages stored > in > >> >> the voltage table which are supported for the domain. > >> >> > >> >> For example, OMAP3430 core domain does not use 1.2v and ends > up > >> >> generating a warning on the first transition. > >> >> > >> [..] > >> >> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach- > >> >> omap2/voltage.c > >> >> index 12be525..280ee12 100644 > >> >> --- a/arch/arm/mach-omap2/voltage.c > >> >> +++ b/arch/arm/mach-omap2/voltage.c > >> [..] > >> >> /* Generic voltage parameters */ > >> >> - vdd->curr_volt = 120; > >> > Where do you update this parameter upon initialization? Shouldn't > you > >> read > >> > the VP register and find the actual current voltage and update this > >> param? > >> > >> The sequence is as follows: > >> a) omapx_vdd_data configure is called as part of sr init sequence. > >> And the curr_volt with this patch is not updated at this stage. > >> b) somewhere down in the boot sequence, pm.c's > >> omap2_set_init_voltage > >> starts up. This looks up the current clk frequency from clock layer of > >> the parent device for the domain, picks up the nominal voltages > stored > >> in the opp layer, then does a omap_voltage_scale_vdd to that > voltage. In > >> omap_voltage_scale_vdd, The current voltage is merely picked off > the vp > >> (in _pre_volt_scale). the last step it does is to setup vdd->curr_volt. > >> This can then be used by dvfs layer etc to make appropriate > decisions. > >> > >> So, No, I dont think I need to update it here, it should happen as > part > >> of the pm init sequence. > >> > >> Could you explain what problem do you foresee by doing this? > > What if omap_voltage_scale_vdd fails when called from > > omap2_set_init_voltage? Or omap2_set_init_voltage returns error > even > > before calling omap_voltage_scale_vdd because it could not find the > > matching voltage for the frequency set by bootloader? > > > > Your assumption that curr_volt is always set by > omap2_set_init_voltage > > need not be true always. > > set_init_voltage's job is to set the initial voltage. if it is > incapable of doing it, I say fix that instead of hacking in some > random number as curr_volt. I never said to use random numbers. All I suggested was that instead of relying on some others function's behavior, read the VP register to fill in the right values. If set_init_voltage succeeds, it will anyway update with right voltage. Vishwa > > The logic involved for set_init_voltage is what we need for filling in > cur_volt. just replicating the logic makes no sense to me. > > Regards, > Nishanth Menon -- 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: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
Sanjeev,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Sanjeev Premi
> Sent: Wednesday, February 23, 2011 11:29 PM
> To: linux-omap@vger.kernel.org
> Cc: Sanjeev Premi
> Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
>
> Add glue logic to hook-up AM35x processors
> with TPS65023.
It seems that you are not really using Voltage layer for any interaction
with TPS65023 as you are not using VP and VC. Then what is the purpose of
registering this PMIC with Voltage layer. I fail to understand the purpose
of this patch series.
Vishwa
>
> Signed-off-by: Sanjeev Premi
> ---
> arch/arm/mach-omap2/am3517_tps.c | 96
> ++
> 1 files changed, 96 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/am3517_tps.c
>
> diff --git a/arch/arm/mach-omap2/am3517_tps.c b/arch/arm/mach-
> omap2/am3517_tps.c
> new file mode 100644
> index 000..cddd7eb
> --- /dev/null
> +++ b/arch/arm/mach-omap2/am3517_tps.c
> @@ -0,0 +1,96 @@
> +/**
> + * Copyright (C) 2011 Texas Instruments Incorporated -
> http://www.ti.com/
> + *
> + * Based on omap_twl.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 "pm.h"
> +
> +/*
> + * TODO: Copy of OMAP3 definitions to get thru compilation.
> + * May not be needed in final implementation. Need to
> + * relook at the the need again.
> + */
> +#define OMAP3_SRI2C_SLAVE_ADDR 0x12
> +#define OMAP3_VDD_MPU_SR_CONTROL_REG 0x00
> +#define OMAP3_VDD_CORE_SR_CONTROL_REG0x01
> +#define OMAP3_VP_CONFIG_ERROROFFSET 0x00
> +#define OMAP3_VP_VSTEPMIN_VSTEPMIN 0x1
> +#define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04
> +#define OMAP3_VP_VLIMITTO_TIMEOUT_US 200
> +
> +#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
> +#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c
> +
> +/**
> + * TBD: Update the formula below.
> + * Needs to be derived from a table.
> + */
> +static unsigned long tps65023_vsel_to_uv(const u8 vsel)
> +{
> + return (((vsel * 250) + 6000)) * 100;
> +}
> +
> +/**
> + * TBD: Update the formula below.
> + * Needs to be derived from a table.
> + */
> +static u8 tps65023_uv_to_vsel(unsigned long uv)
> +{
> + return DIV_ROUND_UP(uv - 60, 25000);
> +}
> +
> +/**
> + * TBD: Just a copy of OMAP3 PMIC info.
> + * Many fields below don't make much sense for AM3517,
> + * but keeping them as is for now.
> + */
> +static struct omap_volt_pmic_info am3517_volt_info = {
> + .slew_rate = 4000,
> + .step_size = 25000,
> + .on_volt= 120,
> + .onlp_volt = 100,
> + .ret_volt = 975000,
> + .off_volt = 60,
> + .volt_setup_time= 0xfff,
> + .vp_erroroffset =
> OMAP3_VP_CONFIG_ERROROFFSET,
> + .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
> + .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
> + .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
> + .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
> + .vp_timeout_us =
> OMAP3_VP_VLIMITTO_TIMEOUT_US,
> + .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
> + .pmic_reg = OMAP3_VDD_CORE_SR_CONTROL_REG,
> + .vsel_to_uv = tps65023_vsel_to_uv,
> + .uv_to_vsel = tps65023_uv_to_vsel,
> +};
> +
> +int __init am3517_tps_init(void)
> +{
> + struct voltagedomain *voltdm;
> +
> + if (!cpu_is_omap3505() && !cpu_is_omap3517())
> + return -ENODEV;
> +
> + voltdm = omap_voltage_domain_lookup("mpu");
> + omap_voltage_register_pmic(voltdm, &am3517_volt_info);
> +
> + return 0;
> +}
> +
> --
> 1.7.2.2
>
> --
> 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 2/3] omap: cpufreq: Split omap1 and omap2plus cpufreq drivers.
> -Original Message-
> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> Sent: Friday, February 25, 2011 11:41 AM
> To: linux-omap@vger.kernel.org
> Cc: khil...@ti.com; vishwanath...@ti.com; Santosh Shilimkar
> Subject: [PATCH 2/3] omap: cpufreq: Split omap1 and omap2plus
> cpufreq drivers.
>
> This patch is an attempt to cleanup the #ifdeferry in the
> omap cpufreq drivers.
>
> The split betwenn omap1 and omap2plus is logical because
> - omap1 doesn't support opp layer.
> - omap1 build is seperate from omap2plus.
>
> Signed-off-by: Santosh Shilimkar
> Cc: Kevin Hilman
> Cc: Vishwanath BS
> ---
> arch/arm/mach-omap1/Makefile |3 +
> .../cpu-omap.c => mach-omap1/omap1-cpufreq.c} | 70 +---
>
> arch/arm/mach-omap2/Makefile |3 +
> .../cpu-omap.c => mach-omap2/omap2plus-cpufreq.c} | 87
> +---
> arch/arm/plat-omap/Makefile|1 -
> 5 files changed, 67 insertions(+), 97 deletions(-)
> copy arch/arm/{plat-omap/cpu-omap.c => mach-omap1/omap1-
> cpufreq.c} (74%)
> rename arch/arm/{plat-omap/cpu-omap.c => mach-omap2/omap2plus-
> cpufreq.c} (76%)
>
> diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-
> omap1/Makefile
> index 6ee1950..02b80f5 100644
> --- a/arch/arm/mach-omap1/Makefile
> +++ b/arch/arm/mach-omap1/Makefile
> @@ -11,6 +11,9 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
> obj-$(CONFIG_OMAP_MPU_TIMER) += time.o
> obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
>
> +# CPUFREQ driver
> +obj-$(CONFIG_CPU_FREQ) += omap1-cpufreq.o
> +
> # Power Management
> obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
>
> diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/mach-
> omap1/omap1-cpufreq.c
> similarity index 74%
> copy from arch/arm/plat-omap/cpu-omap.c
> copy to arch/arm/mach-omap1/omap1-cpufreq.c
> index 1c1b80b..64faf3f 100644
> --- a/arch/arm/plat-omap/cpu-omap.c
> +++ b/arch/arm/mach-omap1/omap1-cpufreq.c
> @@ -1,5 +1,5 @@
> /*
> - * linux/arch/arm/plat-omap/cpu-omap.c
> + * OMAP1 cpufreq driver
> *
> * CPU frequency scaling for OMAP
> *
> @@ -27,31 +27,18 @@
> #include
> #include
>
> -#include
> -#include
> #include
>
> -#if defined(CONFIG_ARCH_OMAP3) &&
> !defined(CONFIG_OMAP_PM_NONE)
> +#include
> #include
> -#include
> -#endif
> +
> +#include
>
> #define VERY_HI_RATE 9
>
> static struct cpufreq_frequency_table *freq_table;
> -
> -#ifdef CONFIG_ARCH_OMAP1
> -#define MPU_CLK "mpu"
> -#elif defined(CONFIG_ARCH_OMAP3)
> -#define MPU_CLK "arm_fck"
> -#else
> -#define MPU_CLK "virt_prcm_set"
> -#endif
> -
> static struct clk *mpu_clk;
>
> -/* TODO: Add support for SDRAM timing changes */
> -
> static int omap_verify_speed(struct cpufreq_policy *policy)
> {
> if (freq_table)
> @@ -85,13 +72,7 @@ static int omap_target(struct cpufreq_policy
> *policy,
> unsigned int target_freq,
> unsigned int relation)
> {
> -#ifdef CONFIG_ARCH_OMAP1
> struct cpufreq_freqs freqs;
> -#endif
> -#if defined(CONFIG_ARCH_OMAP3) &&
> !defined(CONFIG_OMAP_PM_NONE)
> - unsigned long freq;
> - struct device *mpu_dev = omap2_get_mpuss_device();
> -#endif
> int ret = 0;
>
> /* Ensure desired rate is within allowed range. Some govenors
> @@ -101,25 +82,22 @@ static int omap_target(struct cpufreq_policy
> *policy,
> if (target_freq > policy->max)
> target_freq = policy->max;
>
> -#ifdef CONFIG_ARCH_OMAP1
> freqs.old = omap_getspeed(0);
> freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
> freqs.cpu = 0;
>
> if (freqs.old == freqs.new)
> return ret;
> +
> cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> +
> #ifdef CONFIG_CPU_FREQ_DEBUG
> - printk(KERN_DEBUG "cpufreq-omap: transition: %u --> %u\n",
> -freqs.old, freqs.new);
> + pr_info("cpufreq-omap: transition: %u --> %u\n", freqs.old,
> freqs.new);
> #endif
> ret = clk_set_rate(mpu_clk, freqs.new * 1000);
> - cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> -#elif defined(CONFIG_ARCH_OMAP3) &&
> !defined(CONFIG_OMAP_PM_NONE)
> - freq = target_freq * 1000;
> - if (opp_find_freq_ceil(mpu_dev, &freq))
> - omap_pm_cpu_set_freq(freq);
> -#endif
> + if (!ret)
> + cpufreq_notify_transition(&freqs,
> CPUFREQ_POSTCHANGE);
> +
> return ret;
> }
>
> @@ -127,7 +105,7 @@ static int __init omap_cpu_init(struct
> cpufreq_policy *policy)
> {
> int result = 0;
>
> - mpu_clk = clk_get(NULL, MPU_CLK);
> + mpu_clk = clk_get(NULL, "mpu");
> if (IS_ERR(mpu_clk))
> return PTR_ERR(mpu_clk);
>
> @@ -136,13 +114,7 @@ static int __init omap_cpu_init(struct
> cpufreq_policy *policy)
>
> policy->cur = policy->min = policy->max = omap_getspeed(0);
>
> - if (!cpu_is_omap34xx()) {
> - clk_init_cpufreq_t
RE: omap: pm: assumptions on TWL and SmartReflex.
Sanjeev, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > Sent: Thursday, February 24, 2011 12:02 AM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org > Subject: Re: omap: pm: assumptions on TWL and SmartReflex. > > On Wed, Feb 23, 2011 at 19:57, Premi, Sanjeev wrote: > > Hi all, > > > > While trying to suport TPS65023 with AM3517 processor, i realize > > that much of the code has implicit assumption on usage of TWLx0y0 > > PMIC and Smartreflex. > Looking at the data sheet, single SCLK, SDAT makes me think that you > are potentially attempting SR Class2 here. am I right? > > The other potential usage is configure the chip over vcbypass and then > use class3 with reg address 0x6, 0x8 for DCDC1 and LDO1/2-> though i > am not sure how you'd use SR for LDO1/2 with 200mA and non linear > value2voltage.. the other possibility is you have two independent > TPS65023 chips on each rail.. > may be you could briefly explain how you are integrating it all up to > understand the weakness of the datastructures involved.. > > > Check the definition of omap_volt_pmic_info and omap_volt_data. Most of these parameters are required by OMAP for VP/VC configuration. I agree that these parameters need to be segregated better to have PM IC specific, OMAP specific and Board specific parameters. But I do not understand why you are saying that these are TWL specific. Can TPS65023 be controlled via VC/VP over i2c4? If so then these parameters will be needed by VC/VP to control the PM IC. If not, then there is no need to hook up your PMIC with OMAP voltage layer. You can perhaps use regulator framework for setting the voltage. Regards Vishwa > > > > Just to "hack" support we can fill *don't care* values for the > > fields not supported and wrap processing under if (cpu_is_()) > > checks; but this doesn't appear to be a good solution. > yes, there are improvements possible. we probably need to see your > usage to comeup with something that works for all of us > > > > Also, the PMIC specific code doesn't really belong to mach-omap2. > > OR was there a specific reason to keep it here?? > potentially - but there are PMIC specific parameters that need to be > configured for the SR driver to function as well.. > > Regards, > Nishanth Menon > -- > 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 1/3] OMAP3 PM: Deny clock gating only for safe state
Kevin,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Wednesday, March 02, 2011 2:32 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org
> Subject: Re: [PATCH 1/3] OMAP3 PM: Deny clock gating only for safe
> state
>
> Vishwanath BS writes:
>
> > Currently clock gating for MPU and core are denied whenever C1 state
> is
> > selected.
>
> Yes, that is the definition of C1.
>
> > It should be denied only when safe state is selected.
>
> Why?
Clock gating in C1 will reduce overall power consumption and it should not
impact any functionality as well.
>
> This changes the definition and behavior of C1 depending on how it is
> entered. Not a good idea IMO.
I thought of adding a new C state, keeping C1 definition unchanged. Then
we will not get the real power benefit since in case of C1, clock gating
will be prevented. Let me know if you have some suggestion.
Vishwa
>
> Kevin
>
>
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/cpuidle34xx.c | 20 ++--
> > 1 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
> omap2/cpuidle34xx.c
> > index f8e35b3..1e4ec7f 100644
> > --- a/arch/arm/mach-omap2/cpuidle34xx.c
> > +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> > @@ -139,19 +139,9 @@ static int omap3_enter_idle(struct
> cpuidle_device *dev,
> > if (omap_irq_pending() || need_resched())
> > goto return_sleep_time;
> >
> > - if (cx->type == OMAP3_STATE_C1) {
> > - pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
> > - pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
> > - }
> > -
> > /* Execute ARM wfi */
> > omap_sram_idle();
> >
> > - if (cx->type == OMAP3_STATE_C1) {
> > - pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
> > - pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
> > - }
> > -
> > return_sleep_time:
> > getnstimeofday(&ts_postidle);
> > ts_idle = timespec_sub(ts_postidle, ts_preidle);
> > @@ -315,8 +305,18 @@ static int omap3_enter_idle_bm(struct
> cpuidle_device *dev,
> >
> > select_state:
> > dev->last_state = new_state;
> > +
> > + if (new_state == dev->safe_state) {
> > + pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
> > + pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
> > + }
> > ret = omap3_enter_idle(dev, new_state);
> >
> > + if (new_state == dev->safe_state) {
> > + pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
> > + pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
> > + }
> > +
> > /* Restore original PER state if it was modified */
> > if (per_next_state != per_saved_state)
> > pwrdm_set_next_pwrst(per_pd, per_saved_state);
--
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] OMAP36xx PM: Updated C state latencies for OMAP3630
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Wednesday, March 02, 2011 3:15 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org
> Subject: Re: [PATCH 3/3] OMAP36xx PM: Updated C state latencies for
> OMAP3630
>
> Vishwanath BS writes:
>
> > This patch has changes to update the C state latencies for OMAP3630
> and
> > disables the useless C-States, keeping only the optimized ones with
> their
> > corresponding measured latencies.
>
> I think "useless" vs. "optimized" here are not the right words, and
> doesn't summarize the problem being solved.
>
> If I understood Nicole and Vincent's summary it was that there is no
> significant power savings between some of the states, so they are not
> necessary.
Yes, also some of the C states were consuming more power than deeper C
state.
>
> Also, I believe Nicole & Vincent's research applies to both 34xx and
> 36xx.
I need to check. AFAIK, the experiments were done on OMAP3630 boards.
>
> > Only 4 C-states are kept instead of 7
> > C-States:
> > * C1 . MPU WFI clock gated + Core autogating
> > * C3 . MPU CSWR + Core inactive
> > * C5 . MPU CSWR + Core CSWR
> > * C7 . MPU OFF + Core OFF
> >
> > Thanks to Nicole Chaloub and Vincent Bour b...@ti.com>
> > for their investigation.
> >
> > Tested on ZOOM3 board using latest pm branch.
> >
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/board-3630sdp.c | 19
> +++
> > arch/arm/mach-omap2/board-zoom.c| 19
> +++
>
> Why are these added as board-specific changes?
>
> If these are to be the default 3630 CPUidle states, add a default 36xx
> cpuidle_params_table along side the 34xx one and have CPUidle pick the
> right one at runtime.
Yes, I can do that.
Vishwa
>
> Kevin
>
> > 2 files changed, 38 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
> omap2/board-3630sdp.c
> > index 6264564..8d05fc9
> > --- a/arch/arm/mach-omap2/board-3630sdp.c
> > +++ b/arch/arm/mach-omap2/board-3630sdp.c
> > @@ -25,6 +25,24 @@
> > #include "board-flash.h"
> > #include "mux.h"
> > #include "sdram-hynix-h8mbx00u0mer-0em.h"
> > +#include "pm.h"
> > +
> > +static struct cpuidle_params omap36xx_cpuidle_params_table[] = {
> > + /* C1 */
> > + {1, 74, 78, 152},
> > + /* C2 */
> > + {0, 165, 90, 255},
> > + /* C3 */
> > + {1, 163, 180, 345},
> > + /* C4 */
> > + {0, 2852, 605, 3457},
> > + /* C5 */
> > + {1, 800, 366, 2120},
> > + /* C6 */
> > + {0, 4080, 801, 4881},
> > + /* C7 */
> > + {1, 4300, 8794, 159000},
> > +};
> >
> > #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
> >
> > @@ -212,6 +230,7 @@ static void __init omap_sdp_init(void)
> > board_flash_init(sdp_flash_partitions, chip_sel_sdp);
> > enable_board_wakeup_source();
> > usb_ehci_init(&ehci_pdata);
> > + omap3_pm_init_cpuidle(omap36xx_cpuidle_params_table);
> > }
> >
> > MACHINE_START(OMAP_3630SDP, "OMAP 3630SDP board")
> > diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-
> omap2/board-zoom.c
> > index e26754c..6bd364a
> > --- a/arch/arm/mach-omap2/board-zoom.c
> > +++ b/arch/arm/mach-omap2/board-zoom.c
> > @@ -30,6 +30,24 @@
> > #include "mux.h"
> > #include "sdram-micron-mt46h32m32lf-6.h"
> > #include "sdram-hynix-h8mbx00u0mer-0em.h"
> > +#include "pm.h"
> > +
> > +static struct cpuidle_params omap36xx_cpuidle_params_table[] = {
> > + /* C1 */
> > + {1, 74, 78, 152},
> > + /* C2 */
> > + {0, 165, 90, 255},
> > + /* C3 */
> > + {1, 163, 180, 345},
> > + /* C4 */
> > + {0, 2852, 605, 3457},
> > + /* C5 */
> > + {1, 800, 366, 2120},
> > + /* C6 */
> > + {0, 4080, 801, 4881},
> > + /* C7 */
> > + {1, 4300, 8794, 159000},
> > +};
> >
> > #define ZOOM3_EHCI_RESET_GPIO 64
> >
> > @@ -126,6 +144,7 @@ static void __init omap_zoom_init(void)
> > usb_ehci_init(&ehci_pdata);
> > }
> >
> > + omap3_pm_init_cpuidle(omap36xx_cpuidle_params_table);
> > board_nand_init(zoom_nand_partitions,
> > ARRAY_SIZE(zoom_nand_partitions),
> ZOOM_NAND_CS);
> > zoom_debugboard_init();
--
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/1] omap3: Save and restore CM_AUTOIDLE_PLL across off mode
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Monday, March 07, 2011 2:16 PM
> To: Paul Walmsley
> Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH 1/1] omap3: Save and restore CM_AUTOIDLE_PLL
> across off mode
>
> > -Original Message-
> > From: Paul Walmsley [mailto:p...@pwsan.com]
> > Sent: Saturday, March 05, 2011 4:16 AM
> > To: Premi, Sanjeev
> > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > Subject: Re: [PATCH 1/1] omap3: Save and restore
> CM_AUTOIDLE_PLL across
> > off mode
> >
> > Hello Sanjeev,
> >
> > On Thu, 10 Feb 2011, Sanjeev Premi wrote:
> >
> > > As per commit "bb33cc58", ROM code is expected to restore
> > > context related to CORE domain. As part of this change,
> > > CM_AUTOIDLE_PLL is neither saved nor restored.
> >
> > ... by Linux.
> [sp] Yes.
>
> >
> > > This results in loosing the value of AUTO_PERIPH_DPLL.
> >
> > A few questions:
> >
> > - Is ROM code supposed to restore this register?
> [sp] Going by the description of the commit message I referenced, it
> It appears to be the case. I am yet to get official confirmation
> from the ROM code team (usually takes quite long); but all
> experiments (i put them in patch 0/1) suggest so.
> >
> > - Is there a documented list of which registers/bitfields the ROM code
> > will and won't restore?
> [sp] No that I am aware of; but yes I have already requested for same
> since this issue was found.
> >
> > - Are the entire contents of the register lost, or just
> AUTO_PERIPH_DPLL?
> [sp] Just AUTO_PERIPH_DPLL.
As per OMAP3630 TRM Section 26.5, register CM_AUTOIDLE_PLL is supposed to
be restored by ROM code. The PM code should only store these registers
before entering off mode. So only thing that needs to be done in this
patch set is to save these registers.
Vishwa
>
> >
> > > The concern of setting the AUTOIDLE flag before the DPLL
> > > is locked seems valid. Hence, the restoration of this
> > > register is delayed until after the context of PER
> > > domain is restored.
> >
> > Could you explain a little more about this? Is there a hardware
> > limitation where AUTO_PERIPH_DPLL shouldn't be set unless the DPLL
> is
> > locked?
> [sp] This is based on my understanding (and observation) that DPLL may
> take longer to lock after resume. Now if the clock goes to AUTOIDLE
> before it is locked; I am not sure what would be the consequences.
> >
> > >
> > > The patch has been verified on OMAP3EVM by checking value
> > > of CM_AUTOIDLE_PLL register across the suspend/resume
> > > sequence (using devmem) with flags sleep_while_idle and
> > > enable_off_mode set to 1.
> > >
> > > Signed-off-by: Sanjeev Premi
> > > ---
>
> [sp]
> [snip]...[snip]
>
> > >
> > > +/**
> > > + * Restore the contents of CM_AUTOIDLE_PLL register.
> > > + *
> > > + * The implementation below restores AUTO_CORE_DPLL as 'good'
> > redundancy.
> >
> > I don't understand this part. Are the entire contents of the register
> > lost, or just the AUTO_PERIPH_DPLL field?
> >
>
> [sp] As put above, only AUTO_PERIPH_DPLL; but this is based on
> observation
> not a *real specification*; I chose to set the AUTO_CORE_DPLL bit
as
> redundancy.
>
> ~sanjeev
>
> > > + */
> > > +static void pll_mod_restore_autoidle(void)
> > > +{
> > > + u32 ctx = stored_cm_autoidle_pll();
> > > + u32 val = omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
> > > +
> > > + if (ctx & OMAP3430_AUTO_CORE_DPLL_MASK)
> > > + val |= ctx & OMAP3430_AUTO_CORE_DPLL_MASK;
> > > +
> > > + if (ctx & OMAP3430_AUTO_PERIPH_DPLL_MASK)
> > > + val |= ctx & OMAP3430_AUTO_PERIPH_DPLL_MASK;
> > > +
> > > + omap2_cm_write_mod_reg(val, PLL_MOD, CM_AUTOIDLE);
> > > +}
> > > +
> [snip]...[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
--
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: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> -Original Message- > From: Premi, Sanjeev [mailto:pr...@ti.com] > Sent: Monday, March 07, 2011 8:51 PM > To: Sripathy, Vishwanath; linux-omap@vger.kernel.org > Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 > > > -Original Message- > > From: Sripathy, Vishwanath > > Sent: Thursday, February 24, 2011 3:35 PM > > To: Premi, Sanjeev; linux-omap@vger.kernel.org > > Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 > > > > Sanjeev, > > > > > -Original Message- > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > ow...@vger.kernel.org] On Behalf Of Sanjeev Premi > > > Sent: Wednesday, February 23, 2011 11:29 PM > > > To: linux-omap@vger.kernel.org > > > Cc: Sanjeev Premi > > > Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 > > > > > > Add glue logic to hook-up AM35x processors > > > with TPS65023. > > It seems that you are not really using Voltage layer for any interaction > > with TPS65023 as you are not using VP and VC. Then what is the > purpose of > > registering this PMIC with Voltage layer. I fail to understand the > purpose > > of this patch series. > > [sp] Then, can you suggest how do I get the AM35x EVM to boot? Given > the > current limitation of all voltage related data being "extracted" from > the voltage layer - which expects only TWLx0y0 PMICs. Pls use regulator framework for setting the voltage for your PMIC. Vishwa > > > > > Vishwa > > > > > > Signed-off-by: Sanjeev Premi -- 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: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
> -Original Message- > From: Premi, Sanjeev [mailto:pr...@ti.com] > Sent: Tuesday, March 08, 2011 5:56 PM > To: Sripathy, Vishwanath; linux-omap@vger.kernel.org > Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 > > > -Original Message- > > From: Sripathy, Vishwanath > > Sent: Monday, March 07, 2011 10:01 PM > > To: Premi, Sanjeev; linux-omap@vger.kernel.org > > Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 > > [snip]...[snip] > > > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > > > ow...@vger.kernel.org] On Behalf Of Sanjeev Premi > > > > > Sent: Wednesday, February 23, 2011 11:29 PM > > > > > To: linux-omap@vger.kernel.org > > > > > Cc: Sanjeev Premi > > > > > Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 > > > > > > > > > > Add glue logic to hook-up AM35x processors > > > > > with TPS65023. > > > > It seems that you are not really using Voltage layer for any > > interaction > > > > with TPS65023 as you are not using VP and VC. Then what is the > > > purpose of > > > > registering this PMIC with Voltage layer. I fail to understand the > > > purpose > > > > of this patch series. > > > > > > [sp] Then, can you suggest how do I get the AM35x EVM to boot? > Given > > > the > > > current limitation of all voltage related data being "extracted" > > from > > > the voltage layer - which expects only TWLx0y0 PMICs. > > Pls use regulator framework for setting the voltage for your PMIC. > > [sp] If you follow the current framework, voltage.c is ingrained with > OMAP3 initialization and same holds good for opp[_3xxx_data].c. > > It would have been great if current implementation allowed pluggable > interface to a PMIC. As it stands today, it isn't. Pls suggest what kind of pluggable interfaces you are looking for. I would expect basic PM IC initialization to be done as part of corresponding PMIC code and voltage layer is not the place to do PMIC initialization. Vishwa > > Until implemented, workarounds have to be put in place to get > platform(s) > working. Though patch series is being done for AM35x with TPS65023. > The > similar workaround would be required for OMAP3 with TPS65023 (for > example). > > ...and I expect workaround to be simple and unobtrusive. > > See: > core_initcall(omap_voltage_early_init); > device_initcall(omap3_opp_init); > late_initcall(omap2_common_pm_late_init); > > ~sanjeev > > [snip]..[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
RE: [PATCH] OMAP4: Intialize IVA Device in addition to DSP device.
> -Original Message-
> From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
> kernel-boun...@lists.infradead.org] On Behalf Of Shweta Gulati
> Sent: Thursday, March 10, 2011 11:52 AM
> To: linux-omap@vger.kernel.org
> Cc: Shweta Gulati; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH] OMAP4: Intialize IVA Device in addition to DSP device.
>
> OMAP4 has two different Devices IVA and DSP. DSP is bound
> with MPU for DVFS and IVA has its own well defined OPPs.
DSP is not in MPU voltage domain. DSP(Tesla) and IVAHD are in the same
voltage domain. Pls correct this in the commit log.
Vishwa
> This Patch adds IVA init to 'omap2_init_processor_devices'
> and make sure that API 'omap2_set_init_voltage' is called
> for apt dev pointer.
>
> It fixes Error logs:
>
> omap2_set_init_voltage: Invalid parameters!
> omap2_set_init_voltage: Unable to put vdd_iva to its init voltage
>
> Tested on OMAP4430 SDP Board.
> Baseline:
> http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-
> pm.git
> Branch :pm-core
>
> Signed-off-by: Shweta Gulati
> ---
> arch/arm/mach-omap2/pm.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 30af335..49486f5 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -89,6 +89,7 @@ static void omap2_init_processor_devices(void)
> if (cpu_is_omap44xx()) {
> _init_omap_device("l3_main_1", &l3_dev);
> _init_omap_device("dsp", &dsp_dev);
> + _init_omap_device("iva", &iva_dev);
> } else {
> _init_omap_device("l3_main", &l3_dev);
> }
> --
> 1.7.0.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: [RFC][PATCH 0/3] OMAP PM: Voltage layer clean up
> -Original Message- > From: Menon, Nishanth [mailto:n...@ti.com] > Sent: Tuesday, March 15, 2011 8:38 PM > To: Vishwanath BS > Cc: linux-omap@vger.kernel.org > Subject: Re: [RFC][PATCH 0/3] OMAP PM: Voltage layer clean up > > On Tue, Mar 15, 2011 at 20:03, Vishwanath BS > wrote: > > > > This patch series attempts to do some more clean up on OMAP Voltage > layer on top > > of the clean up done by Paul as part of > > https://patchwork.kernel.org/patch/591421/ > > > > These patches are generated against latest omap-for-linus branch on > Tony's tree > > (commit id: 05f689400ea5fa3d71af82f910c8b140f87ad1f3) and tested > on OMAP ZOOM3 > > and OMAP4430 SDP with Smartreflex enabled. > > > > Vishwanath BS (3): > > OMAP PM: Seggregate Voltage layer parameters > > OMAP PM: Add support for bypassing VP/VC in Voltage layer > > OMAP PM: Add Board specific parameters for OMAP Volatge layer > > I dont really see why I need to keep fixing your $subjects, but here > again, > all $subjects, OMAP3+: PM: makes more sense This is not OMAP3 specific. It applies to OMAP4 as well. > > > OMAP PM: Seggregate Voltage layer parameters >^^^ spell check please (tip: in vim, use > ":help spell" to see how to use it while committing itself) Thanks. > > OMAP PM: Add support for bypassing VP/VC in Voltage layer > > OMAP PM: Add Board specific parameters for OMAP Volatge layer > > ^ spell check voltage and I think you should be using > small letters for board and voltage > > > > > arch/arm/mach-omap2/board-4430sdp.c | 52 +++ > > Curious if Panda and other OMAP3 platforms where considered. That's TODO as per my Patch3 commit log. Vishwa > > > arch/arm/mach-omap2/board-zoom.c | 79 > +++ > > arch/arm/mach-omap2/omap_opp_data.h | 8 + > > arch/arm/mach-omap2/omap_twl.c | 113 > > > arch/arm/mach-omap2/opp3xxx_data.c | 50 +++ > > arch/arm/mach-omap2/opp4xxx_data.c | 38 + > > arch/arm/mach-omap2/voltage.c | 179 > - > > arch/arm/mach-omap2/voltage.h | 119 > +++-- > > arch/arm/mach-omap2/voltagedomains3xxx_data.c | 4 + > > arch/arm/mach-omap2/voltagedomains44xx_data.c | 4 + > > 10 files changed, 541 insertions(+), 105 deletions(-) > > > > > Regards, > Nishanth Menon -- 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: [RFC][PATCH 2/3] OMAP PM: Add support for bypassing VP/VC in Voltage layer
> -Original Message-
> From: Menon, Nishanth [mailto:n...@ti.com]
> Sent: Tuesday, March 15, 2011 8:46 PM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC][PATCH 2/3] OMAP PM: Add support for bypassing
> VP/VC in Voltage layer
>
> On Tue, Mar 15, 2011 at 20:03, Vishwanath BS
> wrote:
> > Currently Voltage layer assumes that all PMICs use VP/VC for Voltage
> scaling.
> > There can be some instances where PMIC would want to bypass VP/VC
> for voltage
> > scaling. So make VOltage layer flexible enough to handle this.
> please fix VOltage.
>
> The commit message does'nt actually explain enough. it is too vague.
>
> >
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/omap_twl.c | 5 +
> > arch/arm/mach-omap2/voltage.c | 12 +++-
> > arch/arm/mach-omap2/voltage.h | 6 ++
> > 3 files changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
> omap2/omap_twl.c
> > index f96d4b2..42f66c6 100644
> > --- a/arch/arm/mach-omap2/omap_twl.c
> > +++ b/arch/arm/mach-omap2/omap_twl.c
> > @@ -157,6 +157,7 @@ static struct omap_volt_pmic_info
> omap3_mpu_volt_info = {
> > .onlp_cmd = twl4030_uv_to_vsel,
> > .ret_cmd = twl4030_uv_to_vsel,
> > .off_cmd = twl4030_uv_to_vsel,
> > + .voltage_class = VP_VC_CLASS,
>
> Do you need this all unassigned params in a static struct is 0 which
> is basically VP_VC_CLASS.
I did not get this. You do not need to fill all these parameters if you
are not using VP/VC.
>
> > };
> >
> > static struct omap_volt_pmic_info omap3_core_volt_info = {
> > @@ -176,6 +177,7 @@ static struct omap_volt_pmic_info
> omap3_core_volt_info = {
> > .onlp_cmd = twl4030_uv_to_vsel,
> > .ret_cmd = twl4030_uv_to_vsel,
> > .off_cmd = twl4030_uv_to_vsel,
> > + .voltage_class = VP_VC_CLASS,
> here as well
>
> > };
> >
> > static struct omap_volt_pmic_info omap4_mpu_volt_info = {
> > @@ -195,6 +197,7 @@ static struct omap_volt_pmic_info
> omap4_mpu_volt_info = {
> > .onlp_cmd = twl4030_uv_to_vsel,
> > .ret_cmd = twl4030_uv_to_vsel,
> > .off_cmd = twl4030_uv_to_vsel,
> > + .voltage_class = VP_VC_CLASS,
> again
>
> > };
> >
> > static struct omap_volt_pmic_info omap4_iva_volt_info = {
> > @@ -214,6 +217,7 @@ static struct omap_volt_pmic_info
> omap4_iva_volt_info = {
> > .onlp_cmd = twl4030_uv_to_vsel,
> > .ret_cmd = twl4030_uv_to_vsel,
> > .off_cmd = twl4030_uv_to_vsel,
> > + .voltage_class = VP_VC_CLASS,
> and again
>
> > };
> >
> > static struct omap_volt_pmic_info omap4_core_volt_info = {
> > @@ -233,6 +237,7 @@ static struct omap_volt_pmic_info
> omap4_core_volt_info = {
> > .onlp_cmd = twl4030_uv_to_vsel,
> > .ret_cmd = twl4030_uv_to_vsel,
> > .off_cmd = twl4030_uv_to_vsel,
> > + .voltage_class = VP_VC_CLASS,
> and here
> > };
> >
> > int __init omap4_twl_init(void)
> > diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
> omap2/voltage.c
> > index 2ac990f..73fa3ee 100644
> > --- a/arch/arm/mach-omap2/voltage.c
> > +++ b/arch/arm/mach-omap2/voltage.c
> > @@ -1194,11 +1194,13 @@ int __init omap_voltage_late_init(void)
> > pr_err("%s: Unable to create voltage debugfs main
dir\n",
> > __func__);
> > for (i = 0; i < nr_scalable_vdd; i++) {
> > - if (omap_vdd_data_configure(vdd_info[i]))
> > - continue;
> > - omap_vc_init(vdd_info[i]);
> > - vp_init(vdd_info[i]);
> > - vdd_debugfs_init(vdd_info[i]);
> > + if (vdd_info[i]->pmic_info->voltage_class ==
> VP_VC_CLASS) {
> > + if (omap_vdd_data_configure(vdd_info[i]))
> > + continue;
> > + omap_vc_init(vdd_info[i]);
> > + vp_init(vdd_info[i]);
> > + vdd_debugfs_init(vdd_info[i]);
> > + }
>
> > }
> >
> > return 0;
> > diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-
> omap2/voltage.h
> > index de4e09b..17b1e10
> > --- a/arch/arm/mach-omap2/voltage.h
> > +++ b/arch/arm/mach-omap2/voltage.h
> > @@ -23,6 +23,9 @@
> > #define VOLTSCALE_VPFORCEUPDATE 1
> > #define VOLTSCALE_VCBYPASS 2
> >
> > +#define VP_VC_CLASS 0
> > +#define REGULATOR_CLASS 1
> please - could you ensure namespace is proper in macro usage?
> I dont understand usage difference between VP_VC_CLASS and
> REGULATOR_CLASS
Use regulator class if you do not want to use OMAP Voltage layer.
>
> > +
> > /**
> > * struct omap_vfsm_instance_data - per-voltage manager FSM
> register/bitfield
> > * data
> > @@ -8
RE: [RFC][PATCH 3/3] OMAP PM: Add Board specific parameters for OMAP Volatge layer
> -Original Message-
> From: Menon, Nishanth [mailto:n...@ti.com]
> Sent: Tuesday, March 15, 2011 9:08 PM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC][PATCH 3/3] OMAP PM: Add Board specific parameters
> for OMAP Volatge layer
>
> On Tue, Mar 15, 2011 at 20:03, Vishwanath BS
> wrote:
> > This patch adds board specific parameters for ZOOM3 and OMAP4430
> SDP Boards.
> > The same needs to be done for other OMAP3 and OMAP4 boards once
> the approach
> > is accepted.
>
> Would have been great to see this info in 0/0 - what happens without
> these changes on other boards?
Ok will fix it.
>
> [...]
> > +union omap_volt_board_data zoom_mpu_volt_data = {
> > + .omap3_board_data = {
> > + .vdd_setup_ret = {
> > + .voltsetup = OMAP3_VOLTSETUP_VDD1_RET,
> I disagree this is a board specific param - the help says "setup time
> of the VDDregulators in us" - seems to me that it is PMIC information
Yes. This should be PMIC parameter. Thanks for catching it.
>
> > + .clksetup = OMAP3_CLKSETUP_RET,
> ? why cant i just give oscillator ramp time in uSec?
Clksetup = PRM_VOLTOFFSET + PRM_VOLTSETUP2.. So it is not just oscillator
ramp time.
>
> > + .voltsetup2 = 0,
> why should I as a board developer give this as well, why cant voltage
> layer do addition and save me a param?
Do you want to give 5 other parameters just to save one parameter?
>From the patch, it is very clear how this parameter is calculated. Board
developer just needs to change the values of other required parameters and
this parameter is automatically calculated.
>
> > + },
> > +
> > + .vdd_setup_off = {
> > + .voltsetup = OMAP3_VOLTSETUP_VDD1_OFF,
> > + .clksetup = OMAP3_CLKSETUP_OFF,
> > + .voltsetup2 = OMAP3_VOLTSETUP2,
> > + },
> > + .voltoffset = OMAP3_VOLTOFFSET_OFF
> "offset-time to de-assert sys_offmode when exiting the OFF mode" - how
> am I supposed to measure that? again - why cant voltage layer add
> numbers?
It is not question of mathematical computation here. There are the
parameters that have to be measured manually to find the actual delay.
If your concern is lack of documentation on how to measure it, I can
provide relevant links.
>
> > + }
> > +};
> > +
>
> my overall suggestion - when I fill in board file params - I should say:
> I use PMIC x, i have oscillator with ramp "y" uSec - the params should
> talk my language as a board developers - I dont want to know indepth
> details of voltage VP/VC registers and what they should contain. it is
> upto voltage layer to translate, add, bit shift or do what ever is
> necessary to take my board and pmic level details to register details.
>
> Sorry, even though this is a good start for abstraction, the overall
> motivation is missed, I think we need to work on it more.
The motivation here is to enable different kinds of PMIC and Boards to
work with OMAP Voltage layer (and not just board file params).
For your concern on board file abstraction, I do not think there are
magical formulae to calculate all these parameters based on one parameter.
Some have to be measured manually and probably documentation would help as
to how and what to measure. Pls let me know if you have any such formulae
to calculate these parameters.
Also note that these board file params are required only for OMAP3.
Vishwa
>
>
> Regards,
> Nishanth Menon
--
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: [RFCv2 2/2] AM35x: voltage: Basic initialization
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Sanjeev Premi
> Sent: Wednesday, March 16, 2011 1:02 PM
> To: linux-omap@vger.kernel.org
> Cc: Sanjeev Premi
> Subject: [RFCv2 2/2] AM35x: voltage: Basic initialization
>
> This patch adds the basic initialization of voltage layer
> for AM35x. Since AM35x doesn't support voltage scaling,
> Many functions emply fucntions have been defined to plug
> into existing voltage layer.
>
> Signed-off-by: Sanjeev Premi
> ---
> arch/arm/mach-omap2/voltage.c | 110
> -
> 1 files changed, 109 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
> omap2/voltage.c
> index 2017dc0..a82a55f 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -260,6 +260,40 @@ static struct omap_vdd_info omap3_vdd_info[]
> = {
>
> #define OMAP3_NR_SCALABLE_VDD ARRAY_SIZE(omap3_vdd_info)
>
> +/*
> + * AM35x VDD structures
> + *
> + * In AM35x there neither scalable voltage domain nor any hook-up
> with
> + * voltage controller/processor. However, when trying to re-use the
> hwmod
> + * database for OMAP3, definition of "core" voltage domain is
> necessary.
> + * Else, changes in hwmod data structures grow spirally.
> + *
> + * As a workaround, "core" voltage domain is defined below. The
> definition
> + * doesn't lead to any side-effects.
> + */
> +static struct omap_vdd_info am3517_vdd_info[] = {
> +{
> + .dep_vdd_info = NULL,
> + .nr_dep_vdd = 0,
> + .vp_enabled = false,
> +
> +.voltdm = {
> +.name = "mpu",
> +},
> +},
> +{
> + .dep_vdd_info = NULL,
> + .nr_dep_vdd = 0,
> + .vp_enabled = false,
> +
> +.voltdm = {
> +.name = "core",
> +},
> +},
> +};
> +
> +#define AM3517_NR_SCALABLE_VDD ARRAY_SIZE(am3517_vdd_info)
> +
> /* OMAP4 VDD sturctures */
> static struct omap_vdd_info omap4_vdd_info[] = {
> {
> @@ -374,6 +408,15 @@ static struct omap_volt_data
> omap44xx_vdd_core_volt_data[] = {
> VOLT_DATA_DEFINE(0, 0, 0, 0),
> };
>
> +/* AM35x
> + *
> + * Fields related to SmartReflex and Voltage Processor are set to 0.
> + */
> +static struct omap_volt_data am35xx_vdd_volt_data[] = {
> + VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 0x0, 0x0,
> 0x0),
> + VOLT_DATA_DEFINE(0, 0, 0, 0),
> +};
> +
> /* OMAP 3430 MPU Core VDD dependency table */
> static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
> {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
> @@ -399,6 +442,12 @@ static void (*vp_init) (struct omap_vdd_info
> *vdd);
>
> static int (*vdd_data_configure) (struct omap_vdd_info *vdd);
>
> +static int volt_scale_nop (struct omap_vdd_info *vdd,
> + unsigned long target_volt)
> +{
> + return 0;
> +}
> +
> static u32 omap3_voltage_read_reg(u16 mod, u8 offset)
> {
> return omap2_prm_read_mod_reg(mod, offset);
> @@ -1019,6 +1068,45 @@ static int __init
> omap3_vdd_data_configure(struct omap_vdd_info *vdd)
> return 0;
> }
>
> +/**
> + *Setup VDD related information for AM35x processors
> + */
> +static int __init am3517_vdd_data_configure(struct omap_vdd_info
> *vdd)
> +{
> + if (!vdd->pmic_info) {
> + pr_err("%s: PMIC info requried to configure vdd_%s not"
> + "populated.Hence cannot initialize vdd_%s\n",
> + __func__, vdd->voltdm.name, vdd-
> >voltdm.name);
> + return -EINVAL;
> + }
> +
> + if (!strcmp(vdd->voltdm.name, "mpu") ||
> + !strcmp(vdd->voltdm.name, "core")) {
> + vdd->volt_data = am35xx_vdd_volt_data;
> + } else {
> + pr_warning("%s: vdd_%s does not exist in AM35x\n",
> + __func__, vdd->voltdm.name);
> + return -EINVAL;
> + }
> +
> + /* Generic voltage parameters */
> + vdd->curr_volt = OMAP3430_VDD_MPU_OPP3_UV;
> + vdd->ocp_mod= OCP_MOD;
> + vdd->prm_irqst_reg = OMAP3_PRM_IRQSTATUS_MPU_OFFSET;
> + vdd->read_reg = omap3_voltage_read_reg;
> + vdd->write_reg = omap3_voltage_write_reg;
> + vdd->volt_scale = volt_scale_nop;
> +
> + /* Init the plist */
> + spin_lock_init(&vdd->user_lock);
> + plist_head_init(&vdd->user_list, &vdd->user_lock);
> +
> + /* Init the DVFS mutex */
> + mutex_init(&vdd->scaling_mutex);
> +
> + return 0;
> +}
> +
> /* OMAP4 specific voltage init functions */
> static void __init omap4_vc_init(struct omap_vdd_info *vdd)
> {
> @@ -1908,13 +1996,33 @@ int __init omap_voltage_late_init(void)
> }
>
> /**
> + * AM35x - Empty initialization of voltage controller
> + */
> +static void __init am3517_vc_init(s
RE: [RFC][PATCH 1/3] OMAP PM: Seggregate Voltage layer parameters
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Friday, March 18, 2011 4:51 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC][PATCH 1/3] OMAP PM: Seggregate Voltage layer
> parameters
>
> Vishwanath BS writes:
>
> > Voltage layer takes various parameters which can be broadly classified
> as
> > 1. OMAP/VP specific parameters
> > 2. PMIC specific parameters
> > 3. Board specific parameters
>
> For readability sake, this could be broken up along into 3 patches for
> these 3 items.
OK. I need to check if I can get individual patches compilable when they
are split.
>
> >
> > This patch attempts to categorize the parameters in current voltage
> layer into
> > above buckets. This will make voltage layer to work with different
> kinds of PMIC
> > and boards.
> >
> > TODO: Provide infrastructure to use VC I2C (I2C4) for PMIC
> configuration (useful
> > for cases where PMIC is connected to OMAP only via I2C4.
> >
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/omap_opp_data.h |8 ++
> > arch/arm/mach-omap2/omap_twl.c| 108
> -
> > arch/arm/mach-omap2/opp3xxx_data.c| 50
> > arch/arm/mach-omap2/opp4xxx_data.c| 38 ++
> > arch/arm/mach-omap2/voltage.c | 167
> -
> > arch/arm/mach-omap2/voltage.h | 115
> +++--
> > arch/arm/mach-omap2/voltagedomains3xxx_data.c |4 +
> > arch/arm/mach-omap2/voltagedomains44xx_data.c |4 +
> > 8 files changed, 393 insertions(+), 101 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_opp_data.h
> b/arch/arm/mach-omap2/omap_opp_data.h
> > index c784c12..70d61d2 100644
> > --- a/arch/arm/mach-omap2/omap_opp_data.h
> > +++ b/arch/arm/mach-omap2/omap_opp_data.h
> > @@ -86,11 +86,19 @@ extern int __init omap_init_opp_table(struct
> omap_opp_def *opp_def,
> >
> > extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
> > extern struct omap_volt_data omap34xx_vddcore_volt_data[];
> > +extern struct omap_vp_param omap34xx_mpu_vp_data;
> > +extern struct omap_vp_param omap34xx_core_vp_data;
> > +
> > extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
> > extern struct omap_volt_data omap36xx_vddcore_volt_data[];
> > +extern struct omap_vp_param omap36xx_mpu_vp_data;
> > +extern struct omap_vp_param omap36xx_core_vp_data;
> >
> > extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
> > extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
> > extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
> > +extern struct omap_vp_param omap44xx_mpu_vp_data;
> > +extern struct omap_vp_param omap44xx_iva_vp_data;
> > +extern struct omap_vp_param omap44xx_core_vp_data;
> >
> > #endif /*
> __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
> > diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
> omap2/omap_twl.c
> > index 0a8e74e..f96d4b2 100644
> > --- a/arch/arm/mach-omap2/omap_twl.c
> > +++ b/arch/arm/mach-omap2/omap_twl.c
> > @@ -29,7 +29,6 @@
> > #define OMAP3_VP_VSTEPMIN_VSTEPMIN 0x1
> > #define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04
> > #define OMAP3_VP_VLIMITTO_TIMEOUT_US 200
> > -
> > #define OMAP3430_VP1_VLIMITTO_VDDMIN 0x14
> > #define OMAP3430_VP1_VLIMITTO_VDDMAX 0x42
> > #define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
> > @@ -44,12 +43,10 @@
> > #define OMAP4_VDD_MPU_SR_VOLT_REG 0x55
> > #define OMAP4_VDD_IVA_SR_VOLT_REG 0x5B
> > #define OMAP4_VDD_CORE_SR_VOLT_REG 0x61
> > -
> > #define OMAP4_VP_CONFIG_ERROROFFSET0x00
> > #define OMAP4_VP_VSTEPMIN_VSTEPMIN 0x01
> > #define OMAP4_VP_VSTEPMAX_VSTEPMAX 0x04
> > #define OMAP4_VP_VLIMITTO_TIMEOUT_US 200
> > -
> > #define OMAP4_VP_MPU_VLIMITTO_VDDMIN 0xA
> > #define OMAP4_VP_MPU_VLIMITTO_VDDMAX 0x39
> > #define OMAP4_VP_IVA_VLIMITTO_VDDMIN 0xA
> > @@ -146,101 +143,96 @@ static u8 twl6030_uv_to_vsel(unsigned
> long uv)
> > static struct omap_volt_pmic_info omap3_mpu_volt_info = {
> > .slew_rate = 4000,
> > .step_size = 12500,
> > - .on_volt= 120,
> > - .onlp_volt = 100,
> > - .ret_volt = 975000,
> > - .off_volt = 60,
> > - .volt_setup_time= 0xfff,
> > - .vp_erroroffset =
> OMAP3_VP_CONFIG_ERROROFFSET,
> > - .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
> > - .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
> > + .vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
> > + .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
> > + .pmic_reg = OMAP3_VDD_MPU_SR_CONTROL_REG,
> > + .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
> > + .vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
> > + .vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
>
> Please check the resulting indentation, and be sure it aligns with
existing.
OK
>
> > .vp_vddmin =
RE: cpufreq support for the Beagleboard.
Cpufreq for omap is not mainlined yet. Patches for supporting omap cpufreq are posted at https://patchwork.kernel.org/patch/495021/ Same are available at git://gitorious.org/omap-pm/linux.git omap_dvfs Vishwa > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of javier Martin > Sent: Monday, March 21, 2011 4:12 PM > To: linux-omap@vger.kernel.org > Subject: cpufreq support for the Beagleboard. > > Hi, > I am testing latest 2.6.38 stable kernel with my Beagleboard xM. I > have enabled CONFIG_CPU_FREQ option and several governors. > However, when I boot the board and execute "cpufreq-info" I get the > following: > > root@beagleboard:~# cpufreq-info > cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009 > Report errors and bugs to cpuf...@vger.kernel.org, please. > analyzing CPU 0: > no or unknown cpufreq driver is active on this CPU > maximum transition latency: 0.00 ms. > > I've read some information in this wiki: > http://elinux.org/OMAP_Power_Management > > It seems that cpufreq is still not in mainline but it should be > already on pm branch of omap repository. However, I've also tried > compiling this one and I've got the same problem. > > Could anyone clarify whether cpufreq is supported or not in the > Beagleboard xM and where? > > Thank you. > > -- > Javier Martin > Vista Silicon S.L. > CDTUC - FASE C - Oficina S-345 > Avda de los Castros s/n > 39005- Santander. Cantabria. Spain > +34 942 25 32 60 > www.vista-silicon.com > -- > 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: cpufreq support for the Beagleboard.
> -Original Message- > From: javier Martin [mailto:javier.mar...@vista-silicon.com] > Sent: Monday, March 21, 2011 5:40 PM > To: Vishwanath Sripathy > Cc: linux-omap@vger.kernel.org > Subject: Re: cpufreq support for the Beagleboard. > > Hi, > thank you for your fast answer. > > I've been testing the repository you pointed me and I found that only > 300MHz and 600MHz can be selected in the Beagleboard xM. > Couldn't we work until 1000MHz? 1G is disabled by default in OPP table I suppose. Pls enable it (in omap36xx_opp_def_list) if your board supports it. > > Do you know what's left for those patches to enter mainline? Is > anybody working on it? OMAP cpufreq is undergoing some architecture/design changes and this is WIP. Vishwa > > Thanks. > > -- > Javier Martin > Vista Silicon S.L. > CDTUC - FASE C - Oficina S-345 > Avda de los Castros s/n > 39005- Santander. Cantabria. Spain > +34 942 25 32 60 > www.vista-silicon.com -- 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: cpufreq support for the Beagleboard.
> -Original Message- > From: Matt Johnson [mailto:johns...@crhc.illinois.edu] > Sent: Tuesday, March 22, 2011 12:15 AM > To: Vishwanath Sripathy > Cc: javier Martin; linux-omap@vger.kernel.org > Subject: Re: cpufreq support for the Beagleboard. > > On 03/21/2011 08:24 AM, Vishwanath Sripathy wrote: > >> -Original Message- > >> From: javier Martin [mailto:javier.mar...@vista-silicon.com] > >> Sent: Monday, March 21, 2011 5:40 PM > >> To: Vishwanath Sripathy > >> Cc: linux-omap@vger.kernel.org > >> Subject: Re: cpufreq support for the Beagleboard. > >> > >> Hi, > >> thank you for your fast answer. > >> > >> I've been testing the repository you pointed me and I found that only > >> 300MHz and 600MHz can be selected in the Beagleboard xM. > >> Couldn't we work until 1000MHz? > > 1G is disabled by default in OPP table I suppose. Pls enable it (in > > omap36xx_opp_def_list) if your board supports it. > My understanding was that the mainline kernel needed support for > SmartReflex 1.5 and Adaptive Body Biasing (ABB), as found in TI's > linux-omap-psp 2.6.32, before it was safe to enable the 1GHz OPP on the > DM3730 (for e.g., Beagleboard xM). Is this not the case? Can we really > just flip the bit in the OPP table? Sorry, I should have been more explicit. Yes you need to have ABB and SR enabled before enabling 1G. Vishwa > > >> Do you know what's left for those patches to enter mainline? Is > >> anybody working on it? > > OMAP cpufreq is undergoing some architecture/design changes and > this is > > WIP. > > > > Vishwa > Thanks, > Matt > > >> Thanks. > >> > >> -- > >> Javier Martin > >> Vista Silicon S.L. > >> CDTUC - FASE C - Oficina S-345 > >> Avda de los Castros s/n > >> 39005- Santander. Cantabria. Spain > >> +34 942 25 32 60 > >> www.vista-silicon.com > > -- > > 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/RFC 07/19] OMAP3: voltage: add scalable flag to voltagedomain
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Thursday, March 24, 2011 5:30 AM
> To: linux-omap@vger.kernel.org
> Cc: Paul Walmsely; Benoit Cousson
> Subject: [PATCH/RFC 07/19] OMAP3: voltage: add scalable flag to
> voltagedomain
>
> Add a 'bool scalable' flag to the struct powerdomain and set it for
I suppose you meant "struct voltagedomain".
But shouldn't this flag be part of PMIC struct?
Voltage scalability depends on the kind of VDD supply from PMIC. So even
if OMAP supports voltage scaling, we may not be able to scale the voltage
if PMIC does not support it.
> the MPU_IVA and CORE voltage domains.
>
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/voltage.c |3 +++
> arch/arm/mach-omap2/voltage.h |2 ++
> arch/arm/mach-omap2/voltagedomains3xxx_data.c |2 ++
> 3 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
> omap2/voltage.c
> index f995003..bc944ff 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -1054,6 +1054,9 @@ int __init omap_voltage_late_init(void)
> pr_err("%s: Unable to create voltage debugfs main dir\n",
> __func__);
> list_for_each_entry(voltdm, &voltdm_list, node) {
> + if (!voltdm->scalable)
> + continue;
> +
> if (voltdm->vdd) {
> if (omap_vdd_data_configure(voltdm))
> continue;
> diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-
> omap2/voltage.h
> index 5440298..25cfb5c 100644
> --- a/arch/arm/mach-omap2/voltage.h
> +++ b/arch/arm/mach-omap2/voltage.h
> @@ -53,11 +53,13 @@ struct omap_vfsm_instance_data {
> /**
> * struct voltagedomain - omap voltage domain global structure.
> * @name: Name of the voltage domain which can be used as a unique
> identifier.
> + * @scalable: Whether or not this voltage domain is scalable
> * @node: list_head linking all voltage domains
> * @vdd: to be removed
> */
> struct voltagedomain {
> char *name;
> + bool scalable;
> struct list_head node;
> struct omap_vdd_info *vdd;
> };
> diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
> b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
> index b476ee6..e9664843 100644
> --- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
> +++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
> @@ -61,11 +61,13 @@ static struct omap_vdd_info omap3_vdd2_info =
> {
>
> static struct voltagedomain omap3_voltdm_mpu = {
> .name = "mpu_iva",
> + .scalable = true,
> .vdd = &omap3_vdd1_info,
> };
>
> static struct voltagedomain omap3_voltdm_core = {
> .name = "core",
> + .scalable = true,
> .vdd = &omap3_vdd2_info,
> };
Why is this applicable only for OMAP3 and not for OMAP4?
Vishwa
>
> --
> 1.7.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
RE: [PATCH/RFC 07/19] OMAP3: voltage: add scalable flag to voltagedomain
> -Original Message- > From: Cousson, Benoit [mailto:b-cous...@ti.com] > Sent: Thursday, March 24, 2011 8:24 PM > To: Hilman, Kevin > Cc: Sripathy, Vishwanath; linux-omap@vger.kernel.org; Paul Walmsely > Subject: Re: [PATCH/RFC 07/19] OMAP3: voltage: add scalable flag to > voltagedomain > > On 3/24/2011 3:12 PM, Hilman, Kevin wrote: > > Vishwanath Sripathy writes: > > > >>> -Original Message- > >>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > >>> ow...@vger.kernel.org] On Behalf Of Kevin Hilman > >>> Sent: Thursday, March 24, 2011 5:30 AM > >>> To: linux-omap@vger.kernel.org > >>> Cc: Paul Walmsely; Benoit Cousson > >>> Subject: [PATCH/RFC 07/19] OMAP3: voltage: add scalable flag to > >>> voltagedomain > >>> > >>> Add a 'bool scalable' flag to the struct powerdomain and set it for > >> > >> I suppose you meant "struct voltagedomain". > > > > yes > > > >> But shouldn't this flag be part of PMIC struct? > >> Voltage scalability depends on the kind of VDD supply from PMIC. So > even > >> if OMAP supports voltage scaling, we may not be able to scale the > voltage > >> if PMIC does not support it. > > > > That's a good point. Probably I can drop this flag and just use the > > existence of the various fields of the voltage domain (pmic, vc, vp, > > etc.) to determine if the voltdm can scale. > > Mmm, the scalability is still a characteristic of the OMAP voltage > domain. Some are scalable with a supported range of voltage, some are > not. Then should we need this flag in both Voltage domain as well as PMIC? If both are scalable then only voltage can be scaled I suppose. Vishwa > > So that information is relevant in the voltage domain. Then the > regulator framework will have as well some information about the range > that should match what OMAP is able to do. > > Benoit -- 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] OMAP2+: VC: add SoC-specific op for PMIC register addresses
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Friday, March 25, 2011 5:40 AM
> To: linux-omap@vger.kernel.org
> Cc: Paul Walmsely; Benoit Cousson
> Subject: [PATCH] OMAP2+: VC: add SoC-specific op for PMIC register
> addresses
>
> Add a new SoC-specific operation for setting PMIC register addresses
> in the VC for the voltage configuration register and command
> configuration register.
>
> Some PMICs use a single register for voltage configuration and
> on/retention/off commands, others use separate registers. This patch
> adds a VC operation for setting these registers. The voltage
> configuration register is required, and the command register may
> optionally be zero, meaning it is not used. The command register
> address is only written to the VC if it is non-zero.
What about PRM_VC_VAL_BYPASS register? If a PMIC is connected via only
sr-i2c, then PMIC can be configured only via this register. Shouldn't it
be abstracted as part of this patch or patch series?
Vishwa
>
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/prm.h |1 +
> arch/arm/mach-omap2/prm2xxx_3xxx.c | 38
> +++
> arch/arm/mach-omap2/prm44xx.c | 43
>
> arch/arm/mach-omap2/vc.c |9 +--
> arch/arm/mach-omap2/vc.h |6 -
> arch/arm/mach-omap2/vc3xxx_data.c |5
> arch/arm/mach-omap2/vc44xx_data.c |7 --
> 7 files changed, 84 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-
> omap2/prm.h
> index 4daee4a..49f9e78 100644
> --- a/arch/arm/mach-omap2/prm.h
> +++ b/arch/arm/mach-omap2/prm.h
> @@ -32,6 +32,7 @@
> */
> struct omap_prm_vc_ops {
> int (*set_i2c_slave_addr)(u8 vc_id, u8 addr);
> + int (*set_pmic_reg_addrs)(u8 vc_id, u8 volt_addr, u8 cmd_addr);
> };
>
> extern struct omap_prm_vc_ops omap3_prm_vc_ops;
> diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-
> omap2/prm2xxx_3xxx.c
> index b0cc855..4d7fe1a 100644
> --- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
> +++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
> @@ -162,14 +162,20 @@ int omap2_prm_deassert_hardreset(s16
> prm_mod, u8 rst_shift, u8 st_shift)
> */
> struct omap3_prm_vc {
> u32 smps_sa_mask;
> + u32 smps_vol_ra_mask;
> + u32 smps_cmd_ra_mask;
> };
>
> static struct omap3_prm_vc vc_channels[] = {
> [OMAP3_PRM_VC_VDD_MPU_ID] = {
> .smps_sa_mask =
> OMAP3430_PRM_VC_SMPS_SA_SA0_MASK,
> + .smps_vol_ra_mask = OMAP3430_VOLRA0_MASK,
> + .smps_cmd_ra_mask = OMAP3430_CMDRA0_MASK,
> },
> [OMAP3_PRM_VC_VDD_CORE_ID] = {
> .smps_sa_mask =
> OMAP3430_PRM_VC_SMPS_SA_SA1_MASK,
> + .smps_vol_ra_mask = OMAP3430_VOLRA1_MASK,
> + .smps_cmd_ra_mask = OMAP3430_CMDRA1_MASK,
> },
> };
>
> @@ -190,6 +196,38 @@ int omap3_prm_vc_set_i2c_slave_addr(u8
> vc_id, u8 slave_addr)
> return 0;
> }
>
> +/**
> + * omap3_prm_vc_set_pmic_reg_addrs - set PMIC register addresses
> used by VC
> + * @vc: pointer to VC channel
> + * @volt_addr: voltage configuration register address
> + * @cmd_addr: on/retention/off command configuration register
> address
> + *
> + * Programs @volt_addr to the voltage register address (VOL_RA)
> + * register for the VDD channnel @vc_id. If @cmd_addr is
> + * non-zero (for PMICs that use different registers for voltage and
> + * command), write that value to the command configuration register
> + * address (CMD_RA) register.
> + */
> +static int omap3_prm_vc_set_pmic_reg_addrs(u8 vc_id, u8 volt_addr,
> u8 cmd_addr)
> +{
> + struct omap3_prm_vc *vc = &vc_channels[vc_id];
> +
> + omap2_prm_rmw_mod_reg_bits(vc->smps_vol_ra_mask,
> +volt_addr << ffs(vc->smps_vol_ra_mask),
> +OMAP3430_GR_MOD,
> +
> OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET);
> +
> + if (cmd_addr)
> + omap2_prm_rmw_mod_reg_bits(vc-
> >smps_cmd_ra_mask,
> + cmd_addr << ffs(vc-
> >smps_cmd_ra_mask),
> + OMAP3430_GR_MOD,
> +
> OMAP3_PRM_VC_SMPS_CMD_RA_OFFSET);
> +
> + return 0;
> +}
> +
> +
> struct omap_prm_vc_ops omap3_prm_vc_ops = {
> .set_i2c_slave_addr = omap3_prm_vc_set_i2c_slave_addr,
> + .set_pmic_reg_addrs = omap3_prm_vc_set_pmic_reg_addrs,
> };
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-
> omap2/prm44xx.c
> index 2e4bdf5..2758b75 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -202,17 +202,25 @@ void
> omap4_prm_global_warm_sw_reset(void)
> */
> struct omap4_prm_vc {
> u32 smps_sa_mask;
> + u32 smps_vol_ra_mask;
> + u32 smps_cmd_ra_mask;
> };
>
> static struct omap4_prm_vc vc_channels[] = {
> [OMAP4_PRM_VC_VDD_MPU_ID] = {
>
RE: Smartreflex on 'pm-wip/voltdm' Branch
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Gulati, Shweta > Sent: Monday, March 28, 2011 4:23 PM > To: linux-omap@vger.kernel.org; Kevin Hilman > Subject: Smartreflex on 'pm-wip/voltdm' Branch > > Kevin, > > I am testing Smartreflex on your Branch 'pm-wip/voltdm'. There seems > an issue with reading VP registers. > For OMAP3 and OMAP4 reading debugfs entries shows constant voltage. > Logs are: > > OMAP3: > # cat /debug/voltage/vdd_mpu_iva/curr_nominal_volt > 120 > # cat /debug/voltage/vdd_core/curr_nominal_volt > 120 > # echo 1 > /debug/voltage/vdd_mpu_iva/smartreflex/autocomp > [ 311.680816] omap_device: smartreflex.0: new worst case activate > latency 0: 91552 > # echo 1 > /debug/voltage/vdd_core/smartreflex/autocomp > # cat /debug/voltage/vdd_core/vp/curr_volt > 90 > # cat /debug/voltage/vdd_mpu_iva/vp/curr_volt > 90 > > > OMAP4: > # cat /debug/voltage/vdd_core/curr_nominal_volt > 120 > # cat /debug/voltage/vdd_mpu/curr_nominal_volt > 1375000 > # cat /debug/voltage/vdd_iva/curr_nominal_volt > 1188000 > # > # echo 1 > /debug/voltage/vdd_mpu/smartreflex/autocomp > [ 61.514038] omap_device: smartreflex.2: new worst case activate > latency 0: 30517 > # echo 1 > /debug/voltage/vdd_core/smartreflex/autocomp > # echo 1 > /debug/voltage/vdd_mpu/smartreflex/autocomp > # > # cat /debug/voltage/vdd_iva/curr_nominal_volt > 1188000 > # cat /debug/voltage/vdd_iva/vp/curr_volt > 120 > # > # echo 1 > /debug/voltage/vdd_iva/smartreflex/autocomp > # cat /debug/voltage/vdd_iva/vp/curr_volt > 812500 > # > # cat /debug/voltage/vdd_mpu/vp/curr_volt > 812500 > # cat /debug/voltage/vdd_core/vp/curr_volt > 812500 > # > > This Issue is not reproduced on 'pm-core' branch, seems in the voltage > Layer Clean up Patches somewhere some thing is goofed up. I did a quick debug on this and found that the root cause of the issue is in usage of ffs (because of this, i2c slave address was configured wrongly in vc). Basically ffs returns the position of the first (least significant) bit set in the word and the least significant bit is position 1 where as our bit operation assumes that least significant position is 0. I tested the attached patch on OMAP3 and it seems to work fine. Kevin, You may want to incorporate this change in your next version if this seems OK to you. Vishwa > > > Thanks, > Regards, > Shweta > -- > 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 vc_fix.patch Description: Binary data
RE: [RFC][PATCH 1/3] OMAP PM: Seggregate Voltage layer parameters
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Saturday, April 02, 2011 5:33 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC][PATCH 1/3] OMAP PM: Seggregate Voltage layer
> parameters
>
> Hi Vishwa,
>
> Vishwanath BS writes:
>
> > Voltage layer takes various parameters which can be broadly
> classified as
> > 1. OMAP/VP specific parameters
> > 2. PMIC specific parameters
> > 3. Board specific parameters
> >
> > This patch attempts to categorize the parameters in current
> voltage layer into
> > above buckets. This will make voltage layer to work with different
> kinds of PMIC
> > and boards.
> >
> > TODO: Provide infrastructure to use VC I2C (I2C4) for PMIC
> configuration (useful
> > for cases where PMIC is connected to OMAP only via I2C4.
> >
> > Signed-off-by: Vishwanath BS
>
> Looking back at this in light of the voltage layer
> cleanup/restructure
> I've been working on, and I have a few more comments/questions.
>
> First, I'm glad to see the various hard-coded setup times cleaned up
> and
> made configuable. Can you redo this on top of the voltage layer
> cleanups in progress (my pm-wip/voltdm_b branch)? More details on
> this
> below...
Sure
>
> [...]
>
> > @@ -44,6 +54,15 @@ struct omap_volt_data
> omap34xx_vddmpu_volt_data[] = {
> > VOLT_DATA_DEFINE(0, 0, 0, 0),
> > };
> >
> > +struct omap_vp_param omap34xx_mpu_vp_data = {
> > + .on_volt= OMAP3_ON_VOLTAGE_UV,
> > + .onlp_volt = OMAP3_ONLP_VOLTAGE_UV,
> > + .ret_volt = OMAP3_RET_VOLTAGE_UV,
> > + .off_volt = OMAP3_OFF_VOLTAGE_UV,
> > + .vp_vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
> > + .vp_vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
> > +};
> > +
>
> I'm glad to see these removed from the PMIC structure since they are
> not
> PMIC-specific, but the _volt fields in this structure are written to
> the
> VC, not the VP, so should not be part of a VP structure.
Ack. Will fix it.
>
> [...]
>
> > @@ -523,15 +523,35 @@ static int
> vp_forceupdate_scale_voltage(struct omap_vdd_info *vdd,
> >
> > static void __init omap3_vfsm_init(struct omap_vdd_info *vdd)
> > {
> > + struct clk *omap_32k_clk;
> > + u32 omap_32k_clk_speed;
> > + unsigned long temp;
> > +
> > /*
> > * Voltage Manager FSM parameters init
> > -* XXX This data should be passed in from the board file
> > */
> > - vdd->write_reg(OMAP3_CLKSETUP, prm_mod_offs,
> OMAP3_PRM_CLKSETUP_OFFSET);
> > - vdd->write_reg(OMAP3_VOLTOFFSET, prm_mod_offs,
> > - OMAP3_PRM_VOLTOFFSET_OFFSET);
> > - vdd->write_reg(OMAP3_VOLTSETUP2, prm_mod_offs,
> > - OMAP3_PRM_VOLTSETUP2_OFFSET);
> > +
> > + omap_32k_clk = clk_get(NULL, "wkup_32k_fck");
> > + if (IS_ERR(omap_32k_clk)) {
> > + pr_warning("%s: Could not get the 32k_clk clk to
> calculate"
> > + "various vdd_%s params\n", __func__, vdd-
> >voltdm.name);
> > + return;
> > + }
> > + omap_32k_clk_speed = clk_get_rate(omap_32k_clk);
> > + clk_put(omap_32k_clk);
>
> You probably don't need to do a clk_get/clk_get_rate/clk_put of the
> 32k
> clock, since we know what the rate of that clock is already. :)
:-) I will optimize this.
>
> IOW, 'omap_32k_clk_speed = (32 << 10)' should suffice.
>
> > + temp = vdd->board_data-
> >omap3_board_data.vdd_setup_off.clksetup;
> > + temp = temp * omap_32k_clk_speed / (1000 * 1000) + 1;
> > + vdd->write_reg(temp, prm_mod_offs, OMAP3_PRM_CLKSETUP_OFFSET);
> > +
> > + temp = vdd->board_data-
> >omap3_board_data.vdd_setup_off.voltsetup2;
> > + temp = temp * omap_32k_clk_speed / (1000 * 1000) + 1;
> > + vdd->write_reg(temp, prm_mod_offs,
> OMAP3_PRM_VOLTSETUP2_OFFSET);
> > +
> > + temp = vdd->board_data->omap3_board_data.voltoffset;
> > + temp = temp * omap_32k_clk_speed / (1000 * 1000) + 1;
> > + vdd->write_reg(temp, prm_mod_offs,
> OMAP3_PRM_VOLTOFFSET_OFFSET);
>
> According to the TRM (vZK, section 4.12.5.1.2), the VOLTOFFSET value
> should be calculated based on the CLKSETUP and VOLTSETUP2 registers,
> so
> we probably don't need a configurable value for this.
Yes..I am planning to remove these parameters being exposed to board file
and keep only minimal things (like oscillator ramp and ramp down time) in
boaord file. We should be able calculate these parameters based on these
generic parameters.
>
> [...]
>
> > @@ -139,6 +163,61 @@ struct omap_vdd_info {
> > unsigned long target_volt);
> > };
> >
> > +/**
> > + * omap3_vdd_setuptime - vdd set up time info
> > + * @voltsetup : setup time of the VDDregulators in us
> > + * @clksetup : setup time of the oscillator system clock
> (sys_clk) in us
> > + * @voltsetup2 : Overall setup time of VDDregulators in us
> > + */
> > +struct omap3_vdd_setuptime {
> > + u16 voltsetup;
> > + u16 clksetup;
> > + u16 voltsetup2;
> > +};
> > +
> > +/**
> > + * omap3_volt_board_data - vdd
RE: [PATCH 08/13] OMAP3: cpufreq driver changes for DVFS support
> -Original Message-
> From: Jarkko Nikula [mailto:jhnik...@gmail.com]
> Sent: Wednesday, April 13, 2011 7:13 AM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Santosh
> Shilimkar
> Subject: Re: [PATCH 08/13] OMAP3: cpufreq driver changes for DVFS
> support
>
> Hi
>
> A few comments below in case this is still under development as I
> was
> playing a bit with this version on omap3.
There is an updated version of omap cpufreq patches where this issue is
fixed.
https://patchwork.kernel.org/patch/632781/
Regards
Vishwa
>
> On Fri, 21 Jan 2011 19:31:00 +0530
> Vishwanath BS wrote:
>
> > Changes in the omap cpufreq driver for DVFS support.
> >
> > Signed-off-by: Vishwanath BS
> > Cc: Santosh Shilimkar
> > ---
> > arch/arm/plat-omap/cpu-omap.c | 35
> ---
> > 1 files changed, 32 insertions(+), 3 deletions(-)
> >
> ...
> > @@ -85,11 +87,11 @@ static int omap_target(struct cpufreq_policy
> *policy,
> >unsigned int target_freq,
> >unsigned int relation)
> > {
> > -#ifdef CONFIG_ARCH_OMAP1
> > struct cpufreq_freqs freqs;
> > -#endif
> > #if defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
> > unsigned long freq;
> > + int i;
> > + struct cpufreq_freqs freqs_notify;
> > struct device *mpu_dev = omap2_get_mpuss_device();
> > #endif
> > int ret = 0;
> > @@ -116,9 +118,36 @@ static int omap_target(struct cpufreq_policy
> *policy,
> > ret = clk_set_rate(mpu_clk, freqs.new * 1000);
> > cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > #elif defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
> > + freqs.old = omap_getspeed(policy->cpu);;
> > + freqs_notify.new = clk_round_rate(mpu_clk, target_freq * 1000)
> / 1000;
> > + freqs.cpu = policy->cpu;
> > +
> > + if (freqs.old == freqs.new)
> > + return ret;
> > +
>
> Here freqs.new is uninitialized which very likely means that code
> falls
> always through, sets the correct target frequency though, but can
> populate the wrong frequency through the cpufreq_notify_transition
> when
> running the pre notifiers below.
>
> I think the code above meant
>
> freqs_notify.new = clk_round_rate(mpu_clk, target_freq * 1000) /
> 1000;
> ->
> freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
>
> as the freqs_notify is otherwise unused?
>
> However, that doesn't work as the clk_round_rate returns the current
> rate for mpu_clk on omap3 and "freqs.old == freqs.new" is always
> true.
> Looks like there is no round_rate function for arm_fck.
>
> I replaced that with "freqs.new = target_freq;" but this means there
> will be unnecessary fall throughs if the real frequency (eg 124800
> kHz)
> will differ from opp table frequency (eg 125000 kHz) and no real
> changes are happening e.g. with on-demand governor.
>
> > + /* pre notifiers */
> > + for_each_cpu(i, policy->cpus) {
> > + freqs.cpu = i;
> > + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > + }
>
> --
> Jarkko
--
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] OMAP CPUIDLE: CPU Idle latency measurement
From: Vishwanath BS
This patch has instrumentation code for measuring latencies for
various CPUIdle C states for OMAP. Idea here is to capture the
timestamp at various phases of CPU Idle and then compute the sw
latency for various c states. For OMAP, 32k clock is chosen as
reference clock this as is an always on clock. wkup domain memory
(scratchpad memory) is used for storing timestamps. One can see the
worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF
in .config). This information can be used to correctly configure cpu idle
latencies for various C states after adding HW latencies for each of
these sw latencies.
/sys/devices/system/cpu/cpu0/cpuidle/state/actual_latency
/sys/devices/system/cpu/cpu0/cpuidle/state/sleep_latency
/sys/devices/system/cpu/cpu0/cpuidle/state/wkup_latency
THis patch is tested on OMAP ZOOM3 using kevin's pm branch.
Signed-off-by: Vishwanath BS
Cc: linaro-...@lists.linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 58 --
arch/arm/mach-omap2/pm.h |5 ++
arch/arm/mach-omap2/sleep34xx.S | 121 +
drivers/cpuidle/Kconfig |5 ++
drivers/cpuidle/sysfs.c | 16 +-
include/linux/cpuidle.h |3 +
6 files changed, 202 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..398bef8
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
#include
@@ -86,6 +87,11 @@ static struct cpuidle_params cpuidle_params_table[] = {
{1, 1, 3, 30},
};
+#ifdef CONFIG_CPU_IDLE_PROF
+static struct clk *clk_32k;
+#define CONVERT_32K_USEC(lat) (lat * (USEC_PER_SEC/clk_get_rate(clk_32k)))
+#endif
+
static int omap3_idle_bm_check(void)
{
if (!omap3_can_sleep())
@@ -115,21 +121,28 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
* Called from the CPUidle framework to program the device to the
* specified target state selected by the governor.
*/
+
static int omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_state *state)
{
struct omap3_processor_cx *cx = cpuidle_get_statedata(state);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx->mpu_state, core_state = cx->core_state;
+#ifdef CONFIG_CPU_IDLE_PROF
+ int idle_time, latency;
+ long sleep_time, wkup_time, total_sleep_time;
+ long preidle_time, postidle_time;
+#endif
current_cx_state = *cx;
- /* Used to keep track of the total time in idle */
- getnstimeofday(&ts_preidle);
-
local_irq_disable();
local_fiq_disable();
-
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(&ts_preidle);
+#ifdef CONFIG_CPU_IDLE_PROF
+ preidle_time = omap3_sram_get_32k_tick();
+#endif
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
@@ -153,9 +166,39 @@ return_sleep_time:
getnstimeofday(&ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
+#ifdef CONFIG_CPU_IDLE_PROF
+ postidle_time = omap3_sram_get_32k_tick();
+#endif
local_irq_enable();
local_fiq_enable();
+#ifdef CONFIG_CPU_IDLE_PROF
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* take care of overflow */
+ if (postidle_time < preidle_time)
+ postidle_time += (u32) 0x;
+ if (wkup_time < sleep_time)
+ wkup_time += (u32) 0x;
+
+ idle_time = postidle_time - preidle_time;
+ total_sleep_time = wkup_time - sleep_time;
+ latency = idle_time - total_sleep_time;
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* calculate average latency after ignoring sprious ones */
+ if ((total_sleep_time > 0) && (latency > state->actual_latency)
+ && (latency >= 0)) {
+ state->actual_latency = CONVERT_32K_USEC(latency);
+ latency = (sleep_time - preidle_time);
+ state->sleep_latency = CONVERT_32K_USEC(latency);
+ latency = postidle_time - wkup_time;
+ state->wkup_latency = CONVERT_32K_USEC(latency);
+ }
+#endif
+
return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
}
@@ -423,7 +466,9 @@ int __init omap3_idle_init(void)
struct omap3_processor_cx *cx;
struct cpuidle_state *state;
struct cpuidle_device *dev;
-
+#ifdef CONFIG_CPU_IDLE_PROF
+ static struct device dummy_device;
+#endif
mpu_pd = pwrdm_lookup("mpu_pwrdm");
core_pd = pwrdm_lookup("core_pwrdm");
@@ -456,6 +501,9 @@ int __init omap3_idle_init(void)
omap3_cpuidle_update_states();
+#ifde
RE: [PATCH v2 00/11] PM QoS: add a per-device wake-up latency constraint class
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Sent: Sunday, July 03, 2011 12:51 AM > To: jean.pi...@newoldbits.com > Cc: Paul Walmsley; Kevin Hilman; Magnus Damm; Linux PM mailing list; > linux-omap@vger.kernel.org; markgr...@thegnar.org; Jean Pihet > Subject: Re: [PATCH v2 00/11] PM QoS: add a per-device wake-up > latency constraint class > > Hi, > > On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote: > > From: Jean Pihet > > > > This patch set is in an RFC state, for review and comments. > > First off, I'm sorry I couldn't review the patchset earlier. > > > In order to implement the new class in PM QoS the following > changes have been > > made: > > > > 1. Add a new PM QoS class for device wake-up constraints > > (PM_QOS_DEV_WAKEUP_LATENCY). > > Due to the per-device nature of the new class the constraints > lists are stored > > inside the device dev_pm_info struct instead of the internal per- > class > > constraints lists. > > The new class is only available from kernel drivers and so is not > exported to > > user space. > > Have you considered a design in which multiple devices may use the > same > list of constraints? It seems plausible that the constraints will > be the > same, for example, for all Ethernet adapters in the system, in which > case it > will be wasteful to duplicate the list of constraints for each of > them. > > > 2. Added a notification of device insertion/removal from the > device PM framework > > to PM QoS. > > This allows to init/de-init the per-device constraints list upon > device insertion > > and removal. > > RFC state for comments and review, barely tested > > I need to have a look at the details, but in principle this means > that the > per-device lists will be usable only after the devices have been > registered. > In particular, this means that it will only be possible to add new > constraints > after registering the device, which may be too late for some use > cases. > > > 3. Make the pm_qos_add_request API more generic by using a > > struct pm_qos_parameters parameter. This allows easy extension in > the future. > > > > 4. Upon a change of the strongest constraint in the > PM_QOS_DEV_WAKEUP_LATENCY > > class a notification chain mechanism is used to take action on the > system. > > This is the proposed way to have PM QoS and the platform dependant > code to > > interact with each other, cf. 4 below. > > I guess you mean 5.? > > I think we will need something in addition to the notifier here. > For example, > I wouldn't like any core code, like runtime PM or cpuidle, to have > to register > a notifier with PM QoS. > > > The notification mechanism now passes the constraint request > struct ptr in > > order for the notifier callback to have access to the full set of > constraint > > data, e.g. the struct device ptr. > > > > 5. cpuidle interaction with the OMAP3 cpuidle handler > > Since cpuidle is a CPU centric framework it decides the MPU next > power state > > based on the MPU exit_latency and target_residency figures. > > > > The rest of the power domains get their next power state > programmed from > > the PM_QOS_DEV_WAKEUP_LATENCY class of the PM QoS framework, via > the device > > wake-up latency constraints. > > > > Note: the exit_latency and target_residency figures of the MPU > include the MPU > > itself and the peripherals needed for the MPU to execute > instructions (e.g. > > main memory, caches, IRQ controller, MMU etc). > > Some of those peripherals can belong to other power domains than > the MPU > > subsystem and so the corresponding latencies must be included in > those figures. > > > > 6. Update the pm_qos_add_request callers to the generic API > > > > 7. Minor clean-ups and rename of struct fields > > > > Questions: > > 1. How to retrieve the device ptr from a given device driver in > order to add > > a constraint on it? > > 2. The device struct has recently been extended with the power > domain > > information. Can this be used to apply the constraints on power > domains? > > Yes, it can in principle, but that will require some work. > > > On-going developments, patches in preparation: > > 1. write Documentation for the new PM QoS class > > I'd wait with that until the code has settled. > > > 2. validate the constraints framework on OMAP4 HW (done on OMAP3) > > 3. refine the power domains wake-up latency and the cpuidle > figures > > > > Based on the master branch of the linux-omap git tree (3.0.0-rc3). > Compile > > tested using OMAP and x86 generic defconfigs. > > Tested on OMAP3 Beagleboard (ES2.x) with full RETention and OFF > modes. > > More detailed comments will follow. Thanks Rafael for reviewing the patches. Jean is currently on summer vacation for 2 weeks and will take this discussion forward once he is back to work on July 18. Regards Vishwa > > Thanks, > Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-
RE: [PATCH] OMAP: Keypad: Make keypad_data initdata
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Shubhrajyoti D
> Sent: Tuesday, July 12, 2011 12:02 PM
> To: linux-omap@vger.kernel.org
> Cc: Shubhrajyoti D
> Subject: [PATCH] OMAP: Keypad: Make keypad_data initdata
>
> The keypad data is accessed only at init so making it initdata.
> This removes the section mismatch warning.
>
> Reported-by: Kevin Hilman
> Signed-off-by: Shubhrajyoti D
> ---
> arch/arm/mach-omap2/board-4430sdp.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
> omap2/board-4430sdp.c
Is this issue only for OMAP4 SDP? What about Panda, Beagle, OMAP3 SDP
boards?
If it's only for OMAP4, pls correct the subject.
Vishwa
> index 47e6ab9..2b28c7e 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -195,7 +195,7 @@ static struct omap4_keypad_platform_data
> sdp4430_keypad_data = {
> .cols = 8,
> };
>
> -static struct omap_board_data keypad_data = {
> +static struct omap_board_data keypad_data __initdata = {
> .id = 1,
> .pads= keypad_pads,
> .pads_cnt = ARRAY_SIZE(keypad_pads),
> --
> 1.7.1
>
> --
> 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: Issues using runtime API's with console uart
+linux_pm.
Vishwa
> -Original Message-
> From: Govindraj [mailto:govindraj...@gmail.com]
> Sent: Tuesday, July 12, 2011 5:14 PM
> To: linux-omap@vger.kernel.org
> Cc: Kevin Hilman; Paul Walmsley; Basak, Partha; Tony Lindgren;
> Sripathy, Vishwanath; linux-arm-ker...@lists.infradead.org; Rajendra
> Nayak; Shilimkar, Santosh
> Subject: RFC: Issues using runtime API's with console uart
>
> Hi All,
>
> With recent uart runtime conversion I am facing some issues with
> runtime
> API usage with console.
>
> With runtime adaptation the clock cutting is done aggressively with
> get and put.
>
> as below with console_write API in uart code.
>
> serial_omap_console_write(.)
> {
> get_sync();
> .
> .
> .
> put();
> }
>
> serial_omap_set_mctrl(..)
> {
> get_sync();
> .
> .
> .
> put()
> }
>
> Now if debug messages(pr_debug) from hwmod and omap_device are
> enabled
> then get_sync and put will internally have prints which get
> redirected to
> console_write and will call get_sync.
>
> so from a runtime API context I call another runtime API which leads
> to power lock contention, since every runtime API entrant tries to
> get
> a power lock.
>
> To elaborate further from above code snippets consider set_mctrl
> calling get_sync and printk from omap_hwmod calling console_write
> which calls get_sync.
>
> -> leads to get_sync calling get_sync.
>
> similarly with put_sync having prints calling console driver calling
> get_sync
> leading to power_lock contention.
>
> As of today I don't see any clean approaches to be available.
>
> Some of the approaches I am considering is
>
> 1.) let the clock gating for uart be handled with idle path as done
> today with
> prepare and resume calls.
>
> 2.) Aggressively binding all get and put with console lock to
> suppress
> prints from get/put and to printed during console_unlock.
>
> uart_port_enb(..)
> {
> if (console_trylock()) {
> get_sync();
> console_unlock();
> }
> }
>
> Even this approach doesn't seem fool proof, Similarly if I have
> port_disable
> console unlock(has not yet released the console lock)
> will have a print stating uart clock is disabled will call
> console_write
> which will call port_enb since above trylock fails and
> eventually
> might oops out trying
> to print the message as put has already disabled the uart
> clocks.
>
>
> I don't see any clean method rather using approach[1] as of today.
>
> So any suggestions on any other approach will be helpful.
>
> ---
> Thanks,
> Govindraj.R
--
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: [GIT PULL] minimal omap4460 support for v3.1 merge window
Tony, I boot tested this pull request on 4460 Panda and it boots up fine. Regards Vishwa > -Original Message- > From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux- > arm-kernel-boun...@lists.infradead.org] On Behalf Of Tony Lindgren > Sent: Monday, July 11, 2011 1:22 AM > To: Arnd Bergmann > Cc: Thomas Gleixner; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Nicolas Pitre > Subject: Re: [GIT PULL] minimal omap4460 support for v3.1 merge > window > > Correting the email address for Arnd. > > * Tony Lindgren [110709 23:51]: > > Hi Arnd, > > > > Please pull minimal omap4460 support from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap- > 2.6.git 4460 > > > > Regards, > > > > Tony > > > > > > The following changes since commit > 48cb1258e8b0f8c81cfb699b42326c5b2147b3f8: > > Tony Lindgren (1): > > Merge branch 'for_3.1/pm-misc' of > git://git.kernel.org/.../khilman/linux-omap-pm into devel-cleanup > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap- > 2.6.git 4460 > > > > Aneesh V (2): > > OMAP: ID: introduce chip detection for OMAP4460 > > OMAP4: ID: add omap_has_feature for max freq supported > > > > Rajendra Nayak (2): > > OMAP4: PRCM: OMAP4460 specific PRM and CM register bitshifts > > OMAP4: clocks: Update the clock tree with 4460 clock nodes > > > > arch/arm/mach-omap2/clock44xx_data.c | 39 > ++ > > arch/arm/mach-omap2/cm-regbits-44xx.h | 36 > + > > arch/arm/mach-omap2/id.c | 53 > > > arch/arm/mach-omap2/prm-regbits-44xx.h|8 > > arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + > > arch/arm/plat-omap/include/plat/clock.h |2 + > > arch/arm/plat-omap/include/plat/cpu.h | 35 > +++- > > 7 files changed, 162 insertions(+), 12 deletions(-) > > -- > > 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 > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
Kevin/Paul,
I see that this patch is not queued for 3.1 merge window. Any
issues/comments on this patch?
Vishwa
> -Original Message-
> From: Vishwanath BS [mailto:vishwanath...@ti.com]
> Sent: Monday, July 04, 2011 11:11 AM
> To: linux-omap@vger.kernel.org
> Cc: Vishwanath BS; Nishanth Menon
> Subject: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
>
> Add OMAP4460 OPP definitions for voltage and frequencies based on
> OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
>
> The following exceptions are present:
> * Smartreflex support is still on experimental mode: the gains and
> min
> limits are currently pending characterization data. Currently
> OMAP4430 values
> are used.
> * Efuse offset for core OPP100-OV setting is not clear in
> documentation.
> * IVA OPPs beyond OPP100 are disabled due to the delta between max
> OMAP4460
> current requirements and Phoenix Max supply on VCORE2 in the
> default
> configuration - boards which have supply which can support this
> should
> explicitly call opp_enable and enable the same.
> * MPU OPPs > OPPTURBO can easily be detected using a efuse burnt -
> currently
> disabled pending clock changes to support DCC feature.
>
> [n...@ti.com: cleanups and updates from Datamanual]
> Signed-off-by: Nishanth Menon
> Signed-off-by: Vishwanath BS
> ---
> Patch is generated against Patch series "[PATCH v2 0/6] OMAP4: Add
> 4460 base
> support" from Rajendra and boot tested on 4460 and 4430 SDP.
>
> Changes in V2: Updated the commit log as per Nishant's comments
>
> arch/arm/mach-omap2/control.h |1 +
> arch/arm/mach-omap2/omap_opp_data.h |9 ++-
> arch/arm/mach-omap2/opp4xxx_data.c| 96
> ++---
> arch/arm/mach-omap2/voltagedomains44xx_data.c | 14 +++-
> 4 files changed, 105 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-
> omap2/control.h
> index a016c8b..a41b9a7 100644
> --- a/arch/arm/mach-omap2/control.h
> +++ b/arch/arm/mach-omap2/control.h
> @@ -195,6 +195,7 @@
> #define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249
> #define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254
> #define OMAP44XX_CONTROL_FUSE_CORE_OPP1000x257
> +#define OMAP44XX_CONTROL_FUSE_CORE_OPP100OV 0x25A
>
> /* AM35XX only CONTROL_GENERAL register offsets */
> #define AM35XX_CONTROL_MSUSPENDMUX_6(OMAP2_CONTROL_GENERAL +
> 0x0038)
> diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-
> omap2/omap_opp_data.h
> index c784c12..18a750e 100644
> --- a/arch/arm/mach-omap2/omap_opp_data.h
> +++ b/arch/arm/mach-omap2/omap_opp_data.h
> @@ -89,8 +89,11 @@ extern struct omap_volt_data
> omap34xx_vddcore_volt_data[];
> extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
> extern struct omap_volt_data omap36xx_vddcore_volt_data[];
>
> -extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
> -extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
> -extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_mpu_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_iva_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_core_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_mpu_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_iva_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_core_volt_data[];
>
> #endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
> diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
> omap2/opp4xxx_data.c
> index 2293ba2..8c285e4 100644
> --- a/arch/arm/mach-omap2/opp4xxx_data.c
> +++ b/arch/arm/mach-omap2/opp4xxx_data.c
> @@ -1,7 +1,7 @@
> /*
> * OMAP4 OPP table definitions.
> *
> - * Copyright (C) 2010 Texas Instruments Incorporated -
> http://www.ti.com/
> + * Copyright (C) 2010-2011 Texas Instruments Incorporated -
> http://www.ti.com/
> * Nishanth Menon
> * Kevin Hilman
> * Thara Gopinath
> @@ -36,7 +36,7 @@
> #define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
> #define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
>
> -struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
> +struct omap_volt_data omap443x_vdd_mpu_volt_data[] = {
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP50_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP100_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPPTURBO_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
> @@ -48,7 +48,7 @@ struct omap_volt_data omap44xx_vdd_mpu_volt_data[]
> = {
> #define OMAP4430_VDD_IVA_OPP100_UV 1188000
> #define OMAP4430_VDD_IVA_OPPTURBO_UV 130
>
> -struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
> +struct omap_volt_data omap443x_vdd_iva_volt_data[] = {
> VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP50_UV,
> OMAP44XX_CONTROL_FUSE_IVA_OPP50, 0xf4, 0x0c),
> VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP100_UV
RE: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
Kevin, > -Original Message- > From: Kevin Hilman [mailto:khil...@ti.com] > Sent: Tuesday, July 19, 2011 8:47 PM > To: Vishwanath Sripathy > Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Nishanth Menon > Subject: Re: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions > > Vishwanath Sripathy writes: > > > I see that this patch is not queued for 3.1 merge window. Any > > issues/comments on this patch? > > I did not look at this patch as it came late in the development > cycle. > > A quick glance now suggests it has a few minor problems. > > - patch was not Cc's to linux-arm-kernel > - uses 44XX naming which is not used in l-o master Sorry I did not get this point. What do you mean by 44XX naming? I applied this patch against lo master and it seems to apply and compile perfectly fine. Vishwa > > Please update against current l-o tree which has the PRCM/hwmod > updates > from Paul/Benoit as well as the base 4460 support for v3.1. > > Kevin -- 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: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
My mailer seems to have goofed the from email-id. Pls ignore this email. I
have sent another patch correcting the same.
Vishwa
> -Original Message-
> From: y...@dbdp31.itg.ti.com [mailto:y...@dbdp31.itg.ti.com]
> Sent: Thursday, July 21, 2011 10:23 AM
> To: linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; Sripathy, Vishwanath;
> Nishanth Menon
> Subject: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
>
> From: Sripathy, Vishwanath
>
> Add OMAP4460 OPP definitions for voltage and frequencies based on
> OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
>
> The following exceptions are present:
> * Smartreflex support is still on experimental mode: the gains and
> min
> limits are currently pending characterization data. Currently
> OMAP4430 values
> are used.
> * Efuse offset for core OPP100-OV setting is not clear in
> documentation.
> * IVA OPPs beyond OPP100 are disabled due to the delta between max
> OMAP4460
> current requirements and Phoenix Max supply on VCORE2 in the
> default
> configuration - boards which have supply which can support this
> should
> explicitly call opp_enable and enable the same.
> * MPU OPPs > OPPTURBO can easily be detected using a efuse burnt -
> currently
> disabled pending clock changes to support DCC feature.
>
> [n...@ti.com: cleanups and updates from Datamanual]
> Signed-off-by: Nishanth Menon
> Signed-off-by: Vishwanath BS
> ---
> Patch is generated against latest lo master.
> Changes in V2: Updated the commit log as per Nishant's comments.
> Patch has some checkpatch warnings related to line over 80 chars.
> They have
> been retained to keep the readability of the code.
>
> arch/arm/mach-omap2/control.h |1 +
> arch/arm/mach-omap2/omap_opp_data.h |9 ++-
> arch/arm/mach-omap2/opp4xxx_data.c| 96
> ++---
> arch/arm/mach-omap2/voltagedomains44xx_data.c | 14 +++-
> 4 files changed, 105 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-
> omap2/control.h
> index a016c8b..a41b9a7 100644
> --- a/arch/arm/mach-omap2/control.h
> +++ b/arch/arm/mach-omap2/control.h
> @@ -195,6 +195,7 @@
> #define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249
> #define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254
> #define OMAP44XX_CONTROL_FUSE_CORE_OPP1000x257
> +#define OMAP44XX_CONTROL_FUSE_CORE_OPP100OV 0x25A
>
> /* AM35XX only CONTROL_GENERAL register offsets */
> #define AM35XX_CONTROL_MSUSPENDMUX_6(OMAP2_CONTROL_GENERAL +
> 0x0038)
> diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-
> omap2/omap_opp_data.h
> index c784c12..18a750e 100644
> --- a/arch/arm/mach-omap2/omap_opp_data.h
> +++ b/arch/arm/mach-omap2/omap_opp_data.h
> @@ -89,8 +89,11 @@ extern struct omap_volt_data
> omap34xx_vddcore_volt_data[];
> extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
> extern struct omap_volt_data omap36xx_vddcore_volt_data[];
>
> -extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
> -extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
> -extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_mpu_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_iva_volt_data[];
> +extern struct omap_volt_data omap443x_vdd_core_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_mpu_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_iva_volt_data[];
> +extern struct omap_volt_data omap446x_vdd_core_volt_data[];
>
> #endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
> diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
> omap2/opp4xxx_data.c
> index 2293ba2..8c285e4 100644
> --- a/arch/arm/mach-omap2/opp4xxx_data.c
> +++ b/arch/arm/mach-omap2/opp4xxx_data.c
> @@ -1,7 +1,7 @@
> /*
> * OMAP4 OPP table definitions.
> *
> - * Copyright (C) 2010 Texas Instruments Incorporated -
> http://www.ti.com/
> + * Copyright (C) 2010-2011 Texas Instruments Incorporated -
> http://www.ti.com/
> * Nishanth Menon
> * Kevin Hilman
> * Thara Gopinath
> @@ -36,7 +36,7 @@
> #define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
> #define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
>
> -struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
> +struct omap_volt_data omap443x_vdd_mpu_volt_data[] = {
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP50_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP100_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
> VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPPTURBO_UV,
> OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
> @@ -48,7 +48,7 @@ struct omap_volt_data omap44xx_vdd_mpu_volt_data[]
> = {
> #define OMAP4430_VDD_IVA_OPP100_UV 1188000
> #define OMAP4430_VDD_IVA_OPPTURBO_UV 130
>
> -struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
> +struct omap_volt_data omap443x_vdd_iva_volt_data[] = {
> VOL
RE: [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
> -Original Message- > From: Kevin Hilman [mailto:khil...@ti.com] > Sent: Wednesday, October 05, 2011 2:18 AM > To: Vishwanath BS > Cc: linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; moh...@ti.com > Subject: Re: [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence > > Hi Vishwa, > > Vishwanath BS writes: > > > As per OMAP3630 TRM Section 3.5.7.2.2, the right sequence for > enabling IO Daisy > > chain is "The I/O wake-up scheme is enabled by triggering the I/O > daisy chain > > control (Wu clock) by programming a dedicated register > > (PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in the PRCM module.Software > must wait for > > the I/O daisy chain to complete before it transitions the PER > domain to a > > nonfunctional state. This is done by polling a dedicated status > bit in the PRCM > > module (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must > be cleared by > > software when the bit is read to 1". > > > > The original code was polling on a wrong register which is fixed > in this patch. > > Also omap3_enable_io_chain is made non static as it's going to be > used in > > subsequent patches. > > > > Signed-off-by: Vishwanath BS > > A fix for this was posted[1] by Mohan V (added to Cc) back in June. > It > recieved a few minor comments but an updated version was never > posted. > > Maybe you can ping Mohan or update that version fixing the comments > mentioned in that thread. OK. I will update the original patchset from Mohan with your comments and repost. Vishwa > > Thanks, > > Kevin > > [1] http://marc.info/?l=linux-omap&w=2&r=1&s=%27Mohan+V%27&q=b -- 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/4] ARM: OMAP4 PM: Add IO Daisychain support
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Friday, October 07, 2011 1:44 PM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; khil...@ti.com; linux-arm-
> ker...@lists.infradead.org; Rajendra Nayak
> Subject: Re: [PATCH 2/4] ARM: OMAP4 PM: Add IO Daisychain support
>
> Hi
>
> some comments:
>
> On Tue, 4 Oct 2011, Vishwanath BS wrote:
>
> > From: Rajendra Nayak
> >
> > patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in
> OMAP4430
> > Public TRM.
> >
> > Signed-off-by: Rajendra Nayak
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/pm.h |1 +
> > arch/arm/mach-omap2/pm44xx.c | 36
>
> > 2 files changed, 37 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> > index 9a36a7c..2e09d72 100644
> > --- a/arch/arm/mach-omap2/pm.h
> > +++ b/arch/arm/mach-omap2/pm.h
> > @@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
> > extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
> state);
> > extern int omap3_idle_init(void);
> > extern void omap3_enable_io_chain(void);
> > +extern void omap4_trigger_wuclk_ctrl(void);
> >
> > #if defined(CONFIG_PM_OPP)
> > extern int omap3_opp_init(void);
> > diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-
> omap2/pm44xx.c
> > index 59a870b..aa7cff4 100644
> > --- a/arch/arm/mach-omap2/pm44xx.c
> > +++ b/arch/arm/mach-omap2/pm44xx.c
> > @@ -16,8 +16,17 @@
> > #include
> > #include
> >
> > +#include
> > +
> > #include "powerdomain.h"
> > #include
> > +#include "pm.h"
> > +#include "cm-regbits-44xx.h"
> > +#include "cminst44xx.h"
> > +#include "prm-regbits-44xx.h"
> > +#include "prcm44xx.h"
> > +#include "prm44xx.h"
> > +#include "prminst44xx.h"
> >
> > struct power_state {
> > struct powerdomain *pwrdm;
> > @@ -30,6 +39,33 @@ struct power_state {
> >
> > static LIST_HEAD(pwrst_list);
> >
> > +#define MAX_IOPAD_LATCH_TIME 1000
>
> This macro is missing a comment, which should precede it, describing
> what
> this value is.
OK
>
> > +
> > +void omap4_trigger_wuclk_ctrl(void)
> > +{
> > + int i = 0;
> > +
> > + /* Enable GLOBAL_WUEN */
> > + if (!omap4_cminst_read_inst_reg_bits(OMAP4430_PRM_PARTITION,
> > + OMAP4430_PRM_DEVICE_INST,
> OMAP4_PRM_IO_PMCTRL_OFFSET,
> > + OMAP4430_GLOBAL_WUEN_MASK))
>
> The above line doesn't look right. It's accessing a PRM instance
> register
> with omap4_cminst_*()? Shouldn't that be omap4_prminst_*()?
Ya, it would make sense to use omap4_prminst_* though functionally both
have the same effect.
>
> > +
> omap4_prminst_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
> > + OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_PARTITION,
> > + OMAP4430_PRM_DEVICE_INST,
> OMAP4_PRM_IO_PMCTRL_OFFSET);
> > +
> > + /* Trigger WUCLKIN enable */
> > + omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
> OMAP4430_WUCLK_CTRL_MASK,
> > + OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST,
> OMAP4_PRM_IO_PMCTRL_OFFSET);
> > + omap_test_timeout(
> > + ((omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
> OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET)
> > + >> OMAP4430_WUCLK_STATUS_SHIFT) == 1),
> > + MAX_IOPAD_LATCH_TIME, i);
> > + /* Trigger WUCLKIN disable */
> > + omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
> > + OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST,
> OMAP4_PRM_IO_PMCTRL_OFFSET);
> > + return;
> > +}
>
> This function belongs in mach-omap2/prminst44xx.c. I still think it
> would
> be good if we moved all PRM/CM direct register accesses into prm*.c
> or
> cm*.c files in mach-omap2/. Then none of those prm*.h includes
> would be
> needed in pm44xx.c either.
OK. Let me explore that.
Regards
Vishwa
>
> > +
> > #ifdef CONFIG_SUSPEND
> > static int omap4_pm_suspend(void)
> > {
> > --
> > 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
> >
>
>
> - Paul
--
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/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Friday, October 07, 2011 1:50 PM
> To: Vishwanath BS
> Cc: linux-omap@vger.kernel.org; khil...@ti.com; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
>
> Hi
>
> a few comments:
>
> On Tue, 4 Oct 2011, Vishwanath BS wrote:
>
> > As per OMAP3630 TRM Section 3.5.7.2.2, the right sequence for
> enabling IO Daisy
> > chain is "The I/O wake-up scheme is enabled by triggering the I/O
> daisy chain
> > control (Wu clock) by programming a dedicated register
> > (PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in the PRCM module.Software
> must wait for
> > the I/O daisy chain to complete before it transitions the PER
> domain to a
> > nonfunctional state. This is done by polling a dedicated status
> bit in the PRCM
> > module (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must
> be cleared by
> > software when the bit is read to 1".
> >
> > The original code was polling on a wrong register which is fixed
> in this patch.
> > Also omap3_enable_io_chain is made non static as it's going to be
> used in
> > subsequent patches.
>
> This patch should be split into a fix (for the WKEN/WKST bug) and
> then a
> new patch that drops the 'static'. The new patch should also move
> this
> function to prm2xxx_3xxx.c for the same reason that the OMAP4
> version of
> this function should be in prminst44xx.c.
OK, Understood.
>
> In the medium-term, a bunch of the functions from prm2xxx_3xxx.c,
> prminst44xx.c, etc. that are only used by the mach-omap2/pm*.c code
> should
> be moved into the PRM driver that Tero is working on that will live
> in
> drivers/.
OK.
Vishwa
>
> >
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/pm.h |1 +
> > arch/arm/mach-omap2/pm34xx.c |6 +++---
> > 2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> > index 4e166ad..9a36a7c 100644
> > --- a/arch/arm/mach-omap2/pm.h
> > +++ b/arch/arm/mach-omap2/pm.h
> > @@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
> > extern int omap3_can_sleep(void);
> > extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
> state);
> > extern int omap3_idle_init(void);
> > +extern void omap3_enable_io_chain(void);
> >
> > #if defined(CONFIG_PM_OPP)
> > extern int omap3_opp_init(void);
> > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
> omap2/pm34xx.c
> > index 7255d9b..61f1a5b 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -95,7 +95,7 @@ static inline void
> omap3_per_restore_context(void)
> > omap_gpio_restore_context();
> > }
> >
> > -static void omap3_enable_io_chain(void)
> > +void omap3_enable_io_chain(void)
> > {
> > int timeout = 0;
> >
> > @@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
> > /* Do a readback to assure write has been done */
> > omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
> >
> > - while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
> > + while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST) &
> > OMAP3430_ST_IO_CHAIN_MASK)) {
> > timeout++;
> > if (timeout > 1000) {
> > @@ -114,7 +114,7 @@ static void omap3_enable_io_chain(void)
> > return;
> > }
> >
> omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
> > -WKUP_MOD, PM_WKEN);
> > +WKUP_MOD, PM_WKST);
> > }
> > }
> > }
> > --
> > 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
> >
>
>
> - Paul
--
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: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
> -Original Message- > From: Kevin Hilman [mailto:khil...@ti.com] > Sent: Tuesday, November 08, 2011 6:28 AM > To: Vishwanath BS > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain > support via hwmod mux > > Hi Vishwa, > > Vishwanath BS writes: > > > The folowing patch series provides IO Daisychain feature via omap > hwmod mux > > framework. > > The series looks OK at first glance, but needs a refresh against > current > mainline. OK. > > Can you refresh this against Tony's 'fixes' branch and re-test. > > I tested this on OMAP3430/n900 and noticed that it no longer hit off > mode from idle. > > IOW, If I enable UART timeouts and then enable off mode, I don't > actually ever hit off during idle. However, if I do a > suspend/resume I > see it hits off mode, then subsequent attempts to hit off during > idle work. > > Can you investigate this? OK. Let me check that. Regards Vishwa > > Kevin -- 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: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
Hi Kevin, > -Original Message- > From: Vishwanath Sripathy [mailto:vishwanath...@ti.com] > Sent: Tuesday, November 29, 2011 4:53 PM > To: Kevin Hilman > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: RE: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain > support via hwmod mux > > > -Original Message- > > From: Kevin Hilman [mailto:khil...@ti.com] > > Sent: Tuesday, November 08, 2011 6:28 AM > > To: Vishwanath BS > > Cc: linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > > Subject: Re: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain > > support via hwmod mux > > > > Hi Vishwa, > > > > Vishwanath BS writes: > > > > > The folowing patch series provides IO Daisychain feature via > omap > > hwmod mux > > > framework. > > > > The series looks OK at first glance, but needs a refresh against > > current > > mainline. > OK. > > > > Can you refresh this against Tony's 'fixes' branch and re-test. > > > > I tested this on OMAP3430/n900 and noticed that it no longer hit > off > > mode from idle. > > > > IOW, If I enable UART timeouts and then enable off mode, I don't > > actually ever hit off during idle. However, if I do a > > suspend/resume I > > see it hits off mode, then subsequent attempts to hit off during > > idle work. > > > > Can you investigate this? > OK. Let me check that. I rebased these patches against latest Tony's fixes branch and tested it on OMAP3430 SDP. I see that Core enters off mode in idle path after setting UART timeout w/o having to suspend the system. Is there anything else I need to do to see the issue mentioned by you? Regards Vishwa > > Regards > Vishwa > > > > Kevin -- 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: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
--- > >> > Can you refresh this against Tony's 'fixes' branch and re-test. > >> > > >> > I tested this on OMAP3430/n900 and noticed that it no longer > hit > >> off > >> > mode from idle. > >> > > >> > IOW, If I enable UART timeouts and then enable off mode, I > don't > >> > actually ever hit off during idle. However, if I do a > >> > suspend/resume I > >> > see it hits off mode, then subsequent attempts to hit off > during > >> > idle work. > >> > > >> > Can you investigate this? > >> OK. Let me check that. > > I rebased these patches against latest Tony's fixes branch and > tested it > > on OMAP3430 SDP. I see that Core enters off mode in idle path > after > > setting UART timeout w/o having to suspend the system. > > OK, sounds good. > > Do you have a branch that I can test as well? Sure. It's available at git://gitorious.org/omap-pm/linux.git for_3.3/io_daisy_chain Regards Vishwa > > Kevin -- 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: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
Kevin, > -Original Message- > From: Vishwanath Sripathy [mailto:vishwanath...@ti.com] > Sent: Wednesday, November 30, 2011 2:58 PM > To: Kevin Hilman > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: RE: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain > support via hwmod mux > > --- > > >> > Can you refresh this against Tony's 'fixes' branch and re- > test. > > >> > > > >> > I tested this on OMAP3430/n900 and noticed that it no longer > > hit > > >> off > > >> > mode from idle. > > >> > > > >> > IOW, If I enable UART timeouts and then enable off mode, I > > don't > > >> > actually ever hit off during idle. However, if I do a > > >> > suspend/resume I > > >> > see it hits off mode, then subsequent attempts to hit off > > during > > >> > idle work. > > >> > > > >> > Can you investigate this? > > >> OK. Let me check that. > > > I rebased these patches against latest Tony's fixes branch and > > tested it > > > on OMAP3430 SDP. I see that Core enters off mode in idle path > > after > > > setting UART timeout w/o having to suspend the system. > > > > OK, sounds good. > > > > Do you have a branch that I can test as well? > Sure. It's available at > git://gitorious.org/omap-pm/linux.git for_3.3/io_daisy_chain Did you get any chance to test it at your side? Should I post the rebased patches? Regards Vishwa > > Regards > Vishwa > > > > Kevin -- 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: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
Kevin, > -Original Message- > From: Vishwanath Sripathy [mailto:vishwanath...@ti.com] > Sent: Friday, December 02, 2011 10:29 PM > To: Kevin Hilman > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: RE: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain > support via hwmod mux > > Kevin, > > > -Original Message- > > From: Vishwanath Sripathy [mailto:vishwanath...@ti.com] > > Sent: Wednesday, November 30, 2011 2:58 PM > > To: Kevin Hilman > > Cc: linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > > Subject: RE: [PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain > > support via hwmod mux > > > > --- > > > >> > Can you refresh this against Tony's 'fixes' branch and re- > > test. > > > >> > > > > >> > I tested this on OMAP3430/n900 and noticed that it no > longer > > > hit > > > >> off > > > >> > mode from idle. > > > >> > > > > >> > IOW, If I enable UART timeouts and then enable off mode, I > > > don't > > > >> > actually ever hit off during idle. However, if I do a > > > >> > suspend/resume I > > > >> > see it hits off mode, then subsequent attempts to hit off > > > during > > > >> > idle work. > > > >> > > > > >> > Can you investigate this? > > > >> OK. Let me check that. > > > > I rebased these patches against latest Tony's fixes branch and > > > tested it > > > > on OMAP3430 SDP. I see that Core enters off mode in idle path > > > after > > > > setting UART timeout w/o having to suspend the system. > > > > > > OK, sounds good. > > > > > > Do you have a branch that I can test as well? > > Sure. It's available at > > git://gitorious.org/omap-pm/linux.git for_3.3/io_daisy_chain > Did you get any chance to test it at your side? > Should I post the rebased patches? I have rebased these patch series against LO master commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a and same is available here [1]. I have tested these patch series along with Tero's Chain Handler + Govind's UART Runtime series which is available at [2]. Regards Vishwa [1]: git://gitorious.org/omap-pm/linux.git for_3.3/io_daisy_chain_rebased [2]: git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/tmp_rc4_uart_pm_intg > > Regards > Vishwa > > > > Regards > > Vishwa > > > > > > Kevin -- 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] ARM: OMAP3+: PM: introduce a central pmic control
Hi Tero,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Tero Kristo
> Sent: Friday, May 04, 2012 7:27 PM
> To: linux-omap@vger.kernel.org; khil...@ti.com
> Cc: linux-arm-ker...@lists.infradead.org; Nishanth Menon
> Subject: [PATCH 2/3] ARM: OMAP3+: PM: introduce a central pmic
> control
>
> From: Nishanth Menon
>
> Since we are starting to use multiple PMICs in various combinations,
> use the existing .omap_chip = OMAP_CHIP_INIT() to mark the
> structures we are interested in using per OMAP device we
> are currently running on. This mapping is based on the default
> device recommendations from TI. Boards using custom PMICs now
> have an opportunity to register their own custom mapping.
>
> With this we no longer need omap4_twl_init and omap3_twl_int
> instead we introduce a registration mechanism which is PMIC
> generic and move twl implementation to use the same. This allows
> for future OMAP4460 support where there is a mixture of
> PMIC combinations used.
In this patch, you seem to be tying PMIC configuration with a OMAP version
which I think is not quite appropriate. Rather it should be a board
dependent parameter. We have many boards based on 4460 chip with different
PMICs. This implementation will not be able to support all such
configurations.
Vishwa
>
> Signed-off-by: Nishanth Menon
> [t-kri...@ti.com: moved code under twl-common, other minor cleanups]
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/omap_twl.c | 81 ++-
> ---
> arch/arm/mach-omap2/pm.h |9 +---
> arch/arm/mach-omap2/twl-common.c | 55 +-
> arch/arm/mach-omap2/twl-common.h | 27 +
> 4 files changed, 129 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
> omap2/omap_twl.c
> index 7830eae..c8e418e 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -19,8 +19,8 @@
> #include
>
> #include "voltage.h"
> -
> #include "pm.h"
> +#include "twl-common.h"
>
> #define OMAP3_SRI2C_SLAVE_ADDR 0x12
> #define OMAP3_VDD_MPU_SR_CONTROL_REG 0x00
> @@ -170,7 +170,7 @@ static struct omap_voltdm_pmic omap3_core_pmic =
> {
> .uv_to_vsel = twl4030_uv_to_vsel,
> };
>
> -static struct omap_voltdm_pmic omap4_mpu_pmic = {
> +static struct omap_voltdm_pmic twl6030_vcore1_pmic = {
> .slew_rate = 4000,
> .step_size = 12660,
> .vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
> @@ -187,7 +187,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic =
> {
> .uv_to_vsel = twl6030_uv_to_vsel,
> };
>
> -static struct omap_voltdm_pmic omap4_iva_pmic = {
> +static struct omap_voltdm_pmic twl6030_vcore2_pmic = {
> .slew_rate = 4000,
> .step_size = 12660,
> .vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
> @@ -204,7 +204,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic =
> {
> .uv_to_vsel = twl6030_uv_to_vsel,
> };
>
> -static struct omap_voltdm_pmic omap4_core_pmic = {
> +static struct omap_voltdm_pmic twl6030_vcore3_pmic = {
> .slew_rate = 4000,
> .step_size = 12660,
> .startup_time = 500,
> @@ -222,31 +222,9 @@ static struct omap_voltdm_pmic omap4_core_pmic
> = {
> .uv_to_vsel = twl6030_uv_to_vsel,
> };
>
> -int __init omap4_twl_init(void)
> +static int __init twl_set_sr(struct voltagedomain *voltdm)
> {
> - struct voltagedomain *voltdm;
> -
> - if (!cpu_is_omap44xx())
> - return -ENODEV;
> -
> - voltdm = voltdm_lookup("mpu");
> - omap_voltage_register_pmic(voltdm, &omap4_mpu_pmic);
> -
> - voltdm = voltdm_lookup("iva");
> - omap_voltage_register_pmic(voltdm, &omap4_iva_pmic);
> -
> - voltdm = voltdm_lookup("core");
> - omap_voltage_register_pmic(voltdm, &omap4_core_pmic);
> -
> - return 0;
> -}
> -
> -int __init omap3_twl_init(void)
> -{
> - struct voltagedomain *voltdm;
> -
> - if (!cpu_is_omap34xx())
> - return -ENODEV;
> + int r = 0;
>
> /*
>* The smartreflex bit on twl4030 specifies if the setting of
> voltage
> @@ -258,15 +236,50 @@ int __init omap3_twl_init(void)
>* voltage scaling will not function on TWL over I2C_SR.
>*/
> if (!twl_sr_enable_autoinit)
> - omap3_twl_set_sr_bit(true);
> + r = omap3_twl_set_sr_bit(true);
>
> - voltdm = voltdm_lookup("mpu_iva");
> - omap_voltage_register_pmic(voltdm, &omap3_mpu_pmic);
> + return r;
> +}
>
> - voltdm = voltdm_lookup("core");
> - omap_voltage_register_pmic(voltdm, &omap3_core_pmic);
> +static __initdata struct omap_pmic_map omap_twl_map[] = {
> + {
> + .name = "mpu_iva",
> + .cpu = PMIC_CPU_OMAP3,
> + .pmic_data = &omap3_m
RE: [PATCH 6/6] ARM: OMAP3+: SmartReflex Class3: restrict CPU to run on
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
> Sent: Tuesday, March 13, 2012 3:56 PM
> To: linux-omap@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Kevin Hilman
> Cc: Nishanth Menon; Jean Pihet
> Subject: [PATCH 6/6] ARM: OMAP3+: SmartReflex Class3: restrict CPU
> to run on
>
> From: Nishanth Menon
>
> Use SmartReflex AVS Class3 initialization only for OMAP343x family
> of
> processors.
>
> Signed-off-by: Nishanth Menon
> Signed-off-by: Jean Pihet
> ---
> arch/arm/mach-omap2/smartreflex-class3.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
> b/arch/arm/mach-omap2/smartreflex-class3.c
> index 9dcda93..735937a 100644
> --- a/arch/arm/mach-omap2/smartreflex-class3.c
> +++ b/arch/arm/mach-omap2/smartreflex-class3.c
> @@ -11,6 +11,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include "smartreflex.h"
>
> static int sr_class3_enable(struct voltagedomain *voltdm,
> @@ -58,6 +59,10 @@ static struct omap_sr_class_data class3_data = {
> /* Smartreflex Class3 init API to be called from board file */
> static int __init sr_class3_init(void)
> {
> + /* Enable this class only for OMAP343x */
> + if (!cpu_is_omap343x())
> + return -EINVAL;
Wouldn't this break SR on OMAP3630 and OMAP4? Shouldn't this be done once
you have SR1.5 support in mainline?
Vishwa
> +
> pr_info("SmartReflex Class3 initialized\n");
> return sr_register_class(&class3_data);
> }
> --
> 1.7.5.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] OMAP PM: MPU/DMA Latency constraints
This patch has implementation for OMAP MPU/DMA Latency constraints using PM QOS.
Signed-off-by: Vishwanath Sripathy
---
arch/arm/plat-omap/Kconfig|3 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h |9 +-
arch/arm/plat-omap/omap-pm-noop.c | 20 +--
arch/arm/plat-omap/omap-pm.c | 309 +
6 files changed, 328 insertions(+), 17 deletions(-)
create mode 100755 arch/arm/plat-omap/omap-pm.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 286b606..ce544b0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -194,6 +194,9 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool "No-op/debug PM layer"
+config OMAP_PM
+ depends on PM
+ bool "OMAP PM layer implementation"
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 2a15191..fad2475 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM) += omap-pm.o
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..29dc45a
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -145,7 +145,8 @@ static inline int omap1_i2c_add_bus(struct platform_device
*pdev, int bus_id)
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ struct pm_qos_request_list *qos_handle = NULL;
+ omap_pm_set_max_mpu_wakeup_lat(&qos_handle, t);
}
static inline int omap2_i2c_add_bus(struct platform_device *pdev, int bus_id)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..47ba9e6 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,6 +19,7 @@
#include
#include "powerdomain.h"
+#include
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
@@ -86,7 +87,7 @@ void omap_pm_if_exit(void);
/**
* omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
- * @dev: struct device * requesting the constraint
+ * @qos_request: handle for the constraint. The pointer should be initialized
to NULL
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
@@ -118,7 +119,7 @@ void omap_pm_if_exit(void);
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list **qos_request,
long t);
/**
@@ -185,7 +186,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev,
struct device *dev,
/**
* omap_pm_set_max_sdma_lat - set the maximum system DMA transfer start latency
- * @dev: struct device *
+ * @qos_request: handle for the constraint. The pointer should be initialized
to NULL
* @t: maximum DMA transfer start latency in microseconds
*
* Request that the maximum system DMA transfer start latency for this
@@ -210,7 +211,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev,
struct device *dev,
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_sdma_lat(struct device *dev, long t);
+int omap_pm_set_max_sdma_lat(struct pm_qos_request_list **qos_request, long t);
/**
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..af2fe43 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -34,19 +34,17 @@ struct omap_opp *l3_opps;
* Device-driver-originated constraints (via board-*.c files)
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list **pmqos_req,
long t)
{
- if (!dev || t < -1) {
+ if (!pmqos_req || t < -1) {
WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
return -EINVAL;
};
if (t == -1)
- pr_debug("OMAP PM: remove max MPU wakeup latency constraint: "
-"dev %s\n", dev_name(dev));
+ pr_debug("OMAP PM: remove max MPU wakeup latency constraint\n");
else
- pr_debug("OMAP PM: add max MPU wakeup latency constraint: "
-"dev %s, t = %ld usec\n", dev_name(dev), t);
+ pr_debug("OMAP PM: add max MPU wakeup latency constraint: t =
%ld usec\n&
RE: [RFC 1/2] OMAP3+: voltage / oscillator parameter segregation
> -Original Message- > From: Tero Kristo [mailto:t-kri...@ti.com] > Sent: Wednesday, August 03, 2011 8:59 PM > To: linux-omap@vger.kernel.org > Cc: Vishwanath Sripathy > Subject: [RFC 1/2] OMAP3+: voltage / oscillator parameter > segregation > > This patch separates board specific voltage and oscillator ramp / > setup > times from the core code. Things changed: > > - on/sleep/ret/off voltage setup moved from common twl code to > VC / VP data (opp_data.c files) > - added board support for vdd ramp up / down times > - added board support for oscillator setup time declaration > > Todo: split patch into more easily manageable parts. > > Applies on top of pm/wip/voltdm branch, based on work done by > Vishwanath > Sripathy. > > Signed-off-by: Tero Kristo > Cc: Vishwanath Sripathy > --- > arch/arm/mach-omap2/omap_opp_data.h | 15 +++ > arch/arm/mach-omap2/omap_twl.c| 59 -- > arch/arm/mach-omap2/opp3xxx_data.c| 62 ++ > arch/arm/mach-omap2/opp4xxx_data.c| 47 > arch/arm/mach-omap2/prcm.c| 11 ++ > arch/arm/mach-omap2/prm2xxx_3xxx.c|6 + > arch/arm/mach-omap2/prm2xxx_3xxx.h|1 + > arch/arm/mach-omap2/prm44xx.c |7 + > arch/arm/mach-omap2/prm44xx.h |1 + > arch/arm/mach-omap2/vc.c | 153 > + > arch/arm/mach-omap2/vc.h |1 - > arch/arm/mach-omap2/voltage.c | 22 > arch/arm/mach-omap2/voltage.h | 55 - > arch/arm/mach-omap2/voltagedomains3xxx_data.c |8 ++ > arch/arm/mach-omap2/voltagedomains44xx_data.c |8 ++ > arch/arm/mach-omap2/vp.c |4 +- > arch/arm/plat-omap/include/plat/prcm.h|7 + > 17 files changed, 377 insertions(+), 90 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach- > omap2/omap_opp_data.h > index c784c12..b5fe711 100644 > --- a/arch/arm/mach-omap2/omap_opp_data.h > +++ b/arch/arm/mach-omap2/omap_opp_data.h > @@ -86,11 +86,26 @@ extern int __init omap_init_opp_table(struct > omap_opp_def *opp_def, > > extern struct omap_volt_data omap34xx_vddmpu_volt_data[]; > extern struct omap_volt_data omap34xx_vddcore_volt_data[]; > +extern struct omap_vp_param omap34xx_mpu_vp_data; > +extern struct omap_vp_param omap34xx_core_vp_data; > +extern struct omap_vc_param omap34xx_mpu_vc_data; > +extern struct omap_vc_param omap34xx_core_vc_data; > + > extern struct omap_volt_data omap36xx_vddmpu_volt_data[]; > extern struct omap_volt_data omap36xx_vddcore_volt_data[]; > +extern struct omap_vp_param omap36xx_mpu_vp_data; > +extern struct omap_vp_param omap36xx_core_vp_data; > +extern struct omap_vc_param omap36xx_mpu_vc_data; > +extern struct omap_vc_param omap36xx_core_vc_data; > > extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[]; > extern struct omap_volt_data omap44xx_vdd_iva_volt_data[]; > extern struct omap_volt_data omap44xx_vdd_core_volt_data[]; > +extern struct omap_vp_param omap44xx_mpu_vp_data; > +extern struct omap_vp_param omap44xx_iva_vp_data; > +extern struct omap_vp_param omap44xx_core_vp_data; > +extern struct omap_vc_param omap44xx_mpu_vc_data; > +extern struct omap_vc_param omap44xx_iva_vc_data; > +extern struct omap_vc_param omap44xx_core_vc_data; > > #endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */ > diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach- > omap2/omap_twl.c > index f515a1a..d239792 100644 > --- a/arch/arm/mach-omap2/omap_twl.c > +++ b/arch/arm/mach-omap2/omap_twl.c > @@ -30,16 +30,6 @@ > #define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04 > #define OMAP3_VP_VLIMITTO_TIMEOUT_US 200 > > -#define OMAP3430_VP1_VLIMITTO_VDDMIN 0x14 > -#define OMAP3430_VP1_VLIMITTO_VDDMAX 0x42 > -#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18 > -#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c > - > -#define OMAP3630_VP1_VLIMITTO_VDDMIN 0x18 > -#define OMAP3630_VP1_VLIMITTO_VDDMAX 0x3c > -#define OMAP3630_VP2_VLIMITTO_VDDMIN 0x18 > -#define OMAP3630_VP2_VLIMITTO_VDDMAX 0x30 > - > #define OMAP4_SRI2C_SLAVE_ADDR 0x12 > #define OMAP4_VDD_MPU_SR_VOLT_REG0x55 > #define OMAP4_VDD_MPU_SR_CMD_REG 0x56 > @@ -53,13 +43,6 @@ > #define OMAP4_VP_VSTEPMAX_VSTEPMAX 0x04 > #define OMAP4_VP_VLIMITTO_TIMEOUT_US 200 > > -#define OMAP4_VP_MPU_VLIMITTO_VDDMIN 0xA > -#define OMAP4_VP_MPU_VLIMITTO_VDDMAX 0x39 > -#define OMAP4_VP_IVA_VLIMITTO_VDDMIN 0xA > -#define OMAP4_VP_IVA_VLIMITTO_VDDMAX 0x2D > -#define OMAP4_VP_CORE_VLIMITTO_VDDMIN0xA > -#defi
RE: [PATCH v2 2/2] omap_twl: Prevent SR to enable for am3517/am3505devices
> -Original Message-
> From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
> arm-kernel-boun...@lists.infradead.org] On Behalf Of Abhilash K V
> Sent: Tuesday, August 23, 2011 6:51 PM
> To: linux-omap@vger.kernel.org
> Cc: p...@pwsan.com; li...@arm.linux.org.uk; b-cous...@ti.com;
> t...@atomide.com; linux-ker...@vger.kernel.org; Vaibhav Hiremath;
> Abhilash K V; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH v2 2/2] omap_twl: Prevent SR to enable for
> am3517/am3505devices
>
> From: Vaibhav Hiremath
>
> In case of AM3517 & AM3505, Smart Reflex is not applicable so
> we must not enable it. So add check for absence of SR feature
> in omap3_twl_init() and return -ENODEV if absence, else continue.
>
> Signed-off-by: Vaibhav Hiremath
> Signed-off-by: Abhilash K V
> ---
> arch/arm/mach-omap2/id.c |2 +-
> arch/arm/mach-omap2/omap_twl.c|8
> arch/arm/plat-omap/include/plat/cpu.h |2 ++
> 3 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 37efb86..da71098 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -202,7 +202,7 @@ static void __init omap3_check_features(void)
> if (cpu_is_omap3630())
> omap_features |= OMAP3_HAS_192MHZ_CLK;
> if (!cpu_is_omap3505() && !cpu_is_omap3517())
> - omap_features |= OMAP3_HAS_IO_WAKEUP;
> + omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR);
>
> omap_features |= OMAP3_HAS_SDRC;
>
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
> omap2/omap_twl.c
> index 07d6140..47e27b5 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -269,6 +269,14 @@ int __init omap3_twl_init(void)
> if (!cpu_is_omap34xx())
> return -ENODEV;
>
> + /*
> + * In case of AM3517/AM3505 we should not be going down
> + * further, since SR is not applicable there.
> + */
> + if (!omap3_has_sr()) {
> + return -ENODEV;
> + }
I do not understand what has vp_max and vp_min configuration to do with
SR. This parameter indicates the maximum and minimum voltage supported by
respective PM IC.
Vishwa
> +
> if (cpu_is_omap3630()) {
> omap3_mpu_volt_info.vp_vddmin =
> OMAP3630_VP1_VLIMITTO_VDDMIN;
> omap3_mpu_volt_info.vp_vddmax =
> OMAP3630_VP1_VLIMITTO_VDDMAX;
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-
> omap/include/plat/cpu.h
> index 67b3d75..294e015 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -491,6 +491,7 @@ extern u32 omap_features;
> #define OMAP4_HAS_MPU_1GHZ BIT(8)
> #define OMAP4_HAS_MPU_1_2GHZ BIT(9)
> #define OMAP4_HAS_MPU_1_5GHZ BIT(10)
> +#define OMAP3_HAS_SR BIT(11)
>
>
> #define OMAP3_HAS_FEATURE(feat,flag) \
> @@ -507,6 +508,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
> OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
> OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
> OMAP3_HAS_FEATURE(sdrc, SDRC)
> +OMAP3_HAS_FEATURE(sr, SR)
>
> /*
> * Runtime detection of OMAP4 features
> --
> 1.7.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: [RFC 1/2] OMAP3+: voltage / oscillator parameter segregation
> -Original Message- > From: Kevin Hilman [mailto:khil...@ti.com] > Sent: Saturday, August 27, 2011 4:55 AM > To: Menon, Nishanth > Cc: Tero Kristo; linux-omap@vger.kernel.org; Vishwanath Sripathy > Subject: Re: [RFC 1/2] OMAP3+: voltage / oscillator parameter > segregation > > Hi Nishanth, > > "Menon, Nishanth" writes: > > > here is my quick feedback: > > > > > > On Wed, Aug 3, 2011 at 10:29, Tero Kristo wrote: > >> > >> This patch separates board specific voltage and oscillator ramp / > setup > >> times from the core code. Things changed: > >> > >> - on/sleep/ret/off voltage setup moved from common twl code to > >> VC / VP data (opp_data.c files) > >> - added board support for vdd ramp up / down times > >> - added board support for oscillator setup time declaration > >> > >> Todo: split patch into more easily manageable parts. > >> > >> Applies on top of pm/wip/voltdm branch, based on work done by > Vishwanath > >> Sripathy. > >> > >> Signed-off-by: Tero Kristo > >> Cc: Vishwanath Sripathy > > [...] > > >> diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach- > omap2/opp3xxx_data.c > >> index d95f3f9..b5d8294 100644 > >> --- a/arch/arm/mach-omap2/opp3xxx_data.c > >> +++ b/arch/arm/mach-omap2/opp3xxx_data.c > >> @@ -26,6 +26,16 @@ > >> #include "pm.h" > >> > >> /* 34xx */ > >> +/* OMAP VP parameter values */ > >> +#define OMAP3430_VP1_VLIMITTO_VDDMIN 0x14 > >> +#define OMAP3430_VP1_VLIMITTO_VDDMAX 0x42 > >> +#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18 > >> +#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c > > NAK -> we should be using voltages here -> depending on the PMIC > used, > > the rounding factor may not map to TWL4030. > > Agreed. > > > I had posted patch for this earlier I believe in series > > http://marc.info/?l=linux-omap&m=130741297821372&w=2 > > I know you're a bit distracted currently ;) but is there any chance > you > can refresh at least this patch: > > OMAP3+: PM: VP: use uV for max and min voltage limits > > from your series on top of my current pm-wip/voltdm branch? > > If not, maybe point us to an archived version and Tero can pick it > up > and add it to this series. After a quick search, I couldn't find it > in > the marc.info archives. Below link should help I suppose. https://patchwork.kernel.org/patch/855172/ Vishwa > > Thanks, > > Kevin -- 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
