Re: [PATCH v4 05/20] PM / devfreq: Add new passive governor

[MyungJoo Ham]

>   
>  This patch adds the new passive governor for DEVFREQ framework. The following
> governors are already present and used for DVFS (Dynamic Voltage and Frequency
> Scaling) drivers. The following governors are independently used for one 
> device
> driver which don't give the influence to other device drviers and also don't
> receive the effect from other device drivers.
> - ondemand / performance / powersave / userspace
> 
> The passive governor depends on operation of parent driver with specific
> governos extremely and is not able to decide the new frequency by oneself.
> According to the decided new frequency of parent driver with governor,
> the passive governor uses it to decide the appropriate frequency for own
> device driver. The passive governor must need the following information
> from device tree:
> - the source clock and OPP tables
> - the instance of parent device
> 
> For exameple,
> there are one more devfreq device drivers which need to change their source
> clock according to their utilization on runtime. But, they share the same
> power line (e.g., regulator). So, specific device driver is operated as parent
> with ondemand governor and then the rest device driver with passive governor
> is influenced by parent device.
> 
> Suggested-by: Myungjoo Ham <myungjoo@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon <linux.am...@gmail.com>
> ---
>  drivers/devfreq/Kconfig|   9 
>  drivers/devfreq/Makefile   |   1 +
>  drivers/devfreq/devfreq.c  |  47 
>  drivers/devfreq/governor_passive.c | 108 
> +
>  include/linux/devfreq.h|  15 ++
>  5 files changed, 180 insertions(+)
>  create mode 100644 drivers/devfreq/governor_passive.c
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 55ec774f794c..d03f635a93e1 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -64,6 +64,15 @@ config DEVFREQ_GOV_USERSPACE
> Otherwise, the governor does not change the frequnecy
> given at the initialization.
>  
> +config DEVFREQ_GOV_PASSIVE
> + tristate "Passive"
> + help
> +   Sets the frequency by other governors (simple_ondemand, performance,
> +   powersave, usersapce) of a parent devfreq device. This governor
> +   always has the dependency on the chosen frequency from paired
> +   governor. This governor does not change the frequency by oneself
> +   through sysfs entry.

Sets the frequency based on the frequency of its parent devfreq
device. This governor does not change the frequency by itself
through sysfs entries.

> +
>  comment "DEVFREQ Drivers"
>  
>  config ARM_EXYNOS_BUS_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 375ebbb4fcfb..f81c313b4b79 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
[]
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 984c5e9e7bdd..15e58779e4c0 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -190,6 +190,31 @@ static struct devfreq_governor 
> *find_devfreq_governor(const char *name)
>  
>  /* Load monitoring helper functions for governors use */
>  
> +static int update_devfreq_passive(struct devfreq *devfreq, unsigned long 
> freq)
> +{
> + struct devfreq *passive;
> + unsigned long rate;
> + int ret;
> +
> + list_for_each_entry(passive, >passive_dev_list, passive_node) {
> + if (!passive->governor)
> + continue;
> + rate = freq;
> +
> + ret = passive->governor->get_target_freq(passive, );
> + if (ret)
> + return ret;
> +
> + ret = passive->profile->target(passive->dev.parent, , 0);
> + if (ret)
> + return ret;
> +
> + passive->previous_freq = rate;
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * update_devfreq() - Reevaluate the device and configure frequency.
>   * @devfreq: the devfreq instance.
> @@ -233,10 +258,18 @@ int update_devfreq(struct devfreq *devfreq)
>   flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
>   }
>  
> + if (!list_empty(>passive_dev_list)
> + && devfreq->previous_freq > freq)
> + update_devfreq_passive(devfreq, freq);
> +

Could you please comment somewhere appropriate
that the dependent is going to b

Re: [PATCH v4 06/20] PM / devfreq: Add devfreq_get_devfreq_by_phandle()

[MyungJoo Ham]

>   
>  This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
> which can find the instance of devfreq device by using phandle ("devfreq").
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon <linux.am...@gmail.com>

Signed-off-by: MyungJoo Ham <myungjoo@samsung.com>

> ---
>  drivers/devfreq/devfreq.c | 44 
>  include/linux/devfreq.h   |  9 +
>  2 files changed, 53 insertions(+)
> 

Re: [PATCH v4 07/20] PM / devfreq: Show the related information according to governor type

[MyungJoo Ham]

>   
>  This patch modifies the following sysfs entry of DEVFREQ framework
> because the devfreq device using passive governor don't need the same
> information of the devfreq device using rest governor.
> - polling_interval: passive gov don't use the sampling rate.
> - available_governors : passive gov don't be changed on runtime in this 
> version.
> - trans_stat  : passive governor don't support trans_stat in this 
> version.
> 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 

You have a major update that is not mendtioned in the commit message.
(add governor "type")

> ---
>  drivers/devfreq/devfreq.c | 31 
> +--
>  drivers/devfreq/governor.h|  7 +++
>  drivers/devfreq/governor_passive.c|  1 +
>  drivers/devfreq/governor_performance.c|  1 +
>  drivers/devfreq/governor_powersave.c  |  1 +
>  drivers/devfreq/governor_simpleondemand.c |  1 +
>  drivers/devfreq/governor_userspace.c  |  1 +
>  include/linux/devfreq.h   |  2 ++
>  8 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 78ea4cdaa82c..18ad956fec93 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -597,7 +597,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>   goto err_init;
>   }
>  
> - if (!strncmp(devfreq->governor_name, "passive", 7)) {
> + if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
>   struct devfreq *parent_devfreq =
>   ((struct devfreq_passive_data *)data)->parent;

As mentioned in a previous reply, this code may be removed.

>  
> @@ -963,13 +963,23 @@ static ssize_t available_governors_show(struct device 
> *d,
>   struct device_attribute *attr,
>   char *buf)
>  {
> - struct devfreq_governor *tmp_governor;
> + struct devfreq *devfreq = to_devfreq(d);
>   ssize_t count = 0;
>  
>   mutex_lock(_list_lock);
> - list_for_each_entry(tmp_governor, _governor_list, node)
> + if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
>   count += scnprintf([count], (PAGE_SIZE - count - 2),
> -"%s ", tmp_governor->name);
> +"%s ", devfreq->governor->name);
> + } else {
> + struct devfreq_governor *tmp_governor;
> +
> + list_for_each_entry(tmp_governor, _governor_list, node) 
> {
> + if (tmp_governor->type == DEVFREQ_GOV_PASSIVE)
> + continue;
> + count += scnprintf([count], (PAGE_SIZE - count - 2),
> +"%s ", tmp_governor->name);
> + }
> + }

Uh no. As long as we do not have a list of all possible governors
for each device, let's stick with what we've defined in ABI documentation:
show all available governors "in the system".

You MAY have a device that may run both PASSIVE and USERSPACE.

>   mutex_unlock(_list_lock);
>  
>   /* Truncate the trailing space */
> @@ -1006,6 +1016,11 @@ static DEVICE_ATTR_RO(target_freq);
>  static ssize_t polling_interval_show(struct device *dev,
>struct device_attribute *attr, char *buf)
>  {
> + struct devfreq *df = to_devfreq(dev);
> +
> + if (df->governor->type == DEVFREQ_GOV_PASSIVE)
> + return sprintf(buf, "Not Supported.\n");
> +
>   return sprintf(buf, "%d\n", to_devfreq(dev)->profile->polling_ms);
>  }

When polling interval is irrlevent with the governor,
you don't need to print "Not Supported". Instead,
printing "0" is enough, (polling_ms=0 == no polling)
which is what devfreq is doing now.

>  
> @@ -1020,6 +1035,9 @@ static ssize_t polling_interval_store(struct device 
> *dev,
>   if (!df->governor)
>   return -EINVAL;
>  
> + if (df->governor->type == DEVFREQ_GOV_PASSIVE)
> + return -EINVAL;
> +

Please simply return -EINVAL with governor's event_handler with 
DEVFREQ_GOV_INTERVAL
(I see the return value checking is missing at df->governor->event_handler().
You may want to add return value checking there to properly handle what you 
want.)

>   ret = sscanf(buf, "%u", );
>   if (ret != 1)
>   return -EINVAL;
> @@ -1137,11 +1155,12 @@ static ssize_t trans_stat_show(struct device *dev,
>   int i, j;
>   unsigned int max_state = devfreq->profile->max_state;
>  
> + if (max_state == 0 || devfreq->governor->type == DEVFREQ_GOV_PASSIVE)
> + return sprintf(buf, "Not Supported.\n");
> +
>   if (!devfreq->stop_polling &&
>   devfreq_update_status(devfreq, devfreq->previous_freq))
>   return 0;
> - if (max_state == 0)
> -  

Re: [PATCH v4 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[MyungJoo Ham]

>   
>  This patch adds the generic exynos bus frequency driver for AMBA AXI bus
> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
> have the common architecture for bus between DRAM and sub-blocks in SoC.
> This driver can support the generic bus frequency driver for Exynos SoCs.
> 
> In devicetree, Each bus block has a bus clock, regulator, operation-point
> and devfreq-event devices which measure the utilization of each bus block.
> 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 
> 

Chanwoo, could you please show me testing this set of patches in your site?
Please let me know when is ok to visit you.
(I do not have exynos machines right now.)

> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 5134f9ee983d..375ebbb4fcfb 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)   += governor_powersave.o
>  obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)  += governor_userspace.o
>  
>  # DEVFREQ Drivers
> +obj-$(CONFIG_ARCH_EXYNOS)+= exynos/
>  obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/
>  obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/

CONFIG_ARCH_EXYNOS is true if
CONFIG_ARM_EXYNOS4_BUS_DEVFREQ is true 
or
CONFIG_ARM_EXYNOS5_BUS_DEVFREQ is true
Thus, the two lines after you've added have become useless. (dead code)

Please delete them.

[]
> --- /dev/null
> +++ b/drivers/devfreq/exynos/exynos-bus.c
[]
> +static int exynos_bus_target(struct device *dev, unsigned long *freq, u32 
> flags)
> +{
> + struct exynos_bus *bus = dev_get_drvdata(dev);
> + struct dev_pm_opp *new_opp;
> + unsigned long old_freq, new_freq, old_volt, new_volt;
> + int ret = 0;
> +
> + /* Get new opp-bus instance according to new bus clock */
> + rcu_read_lock();
> + new_opp = devfreq_recommended_opp(dev, freq, flags);
> + if (IS_ERR_OR_NULL(new_opp)) {
> + dev_err(dev, "failed to get recommed opp instance\n");
> + rcu_read_unlock();
> + return PTR_ERR(new_opp);
> + }
> +
> + new_freq = dev_pm_opp_get_freq(new_opp);
> + new_volt = dev_pm_opp_get_voltage(new_opp);
> + old_freq = dev_pm_opp_get_freq(bus->curr_opp);
> + old_volt = dev_pm_opp_get_voltage(bus->curr_opp);
> + rcu_read_unlock();
> +
> + if (old_freq == new_freq)
> + return 0;
> +
> + /* Change voltage and frequency according to new OPP level */
> + mutex_lock(>lock);
> +
> + if (old_freq < new_freq) {
> + ret = regulator_set_voltage(bus->regulator, new_volt, new_volt);

Setting the maximum volt same as the minimum volt is not recommended.
Especially for any DVFS mechanisms, I recommend to set values as:
min_volt = minimum voltage that does not harm the stability
max_volt = maximum voltage that does not break the circuit

Please refer to /include/linux/regulator/driver.h
"@set_voltage" comments.

For the rest of regulator_set_voltage usages, I'd say the same.

[]
> +static int exynos_bus_get_dev_status(struct device *dev,
> +  struct devfreq_dev_status *stat)
> +{
> + struct exynos_bus *bus = dev_get_drvdata(dev);
> + struct devfreq_event_data edata;
> + int ret;
> +
> + rcu_read_lock();
> + stat->current_frequency = dev_pm_opp_get_freq(bus->curr_opp);
> + rcu_read_unlock();
> +
> + ret = exynos_bus_get_event(bus, );
> + if (ret < 0) {
> + stat->total_time = stat->busy_time = 0;
> + goto err;
> + }
> +
> + stat->busy_time = (edata.load_count * 100) / bus->ratio;
> + stat->total_time = edata.total_count;
> +
> + dev_dbg(dev, "Usage of devfreq-event : %ld/%ld\n", stat->busy_time,
> + stat->total_time);

These two values are unsigned long.

[]
> +static int exynos_bus_parse_of(struct device_node *np,
> +   struct exynos_bus *bus)
> +{
> + struct device *dev = bus->dev;
> + unsigned long rate;
> + int i, ret, count, size;
> +
> + /* Get the clock to provide each bus with source clock */
> + bus->clk = devm_clk_get(dev, "bus");
> + if (IS_ERR(bus->clk)) {
> + dev_err(dev, "failed to get bus clock\n");
> + return PTR_ERR(bus->clk);
> + }
> +
> + ret = clk_prepare_enable(bus->clk);
> + if (ret < 0) {
> + dev_err(dev, "failed to get enable clock\n");
> + return ret;
> + }

[]

> +err_regulator:
> + regulator_disable(bus->regulator);
> +err_opp:
> + dev_pm_opp_of_remove_table(dev);
> +
> + return ret;

No clk_disable_unprepare() somewhere in the error handling routines?

[]

> +#ifdef CONFIG_PM_SLEEP
> +static int exynos_bus_resume(struct device *dev)
> +{
[]
> + ret = regulator_enable(bus->regulator);
[]
> +}
> +

Re: [PATCH v4 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[MyungJoo Ham]

>   
>  This patch adds the documentation for generic exynos bus frequency
> driver.
> 
> Signed-off-by: Chanwoo Choi 
> Reviewed-by: Krzysztof Kozlowski 

A little changes following:

> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 93 
> ++
>  1 file changed, 93 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> new file mode 100644
> index ..e32daef328da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -0,0 +1,93 @@
> +* Generic Exynos Bus frequency device
> +
> +The Samsung Exynos SoC have many buses for data transfer between DRAM

+The Samsung Exynos SoC has many buses for data transfer between DRAM

or

+The Samsung Exynos SoCs have many buses for data transfer between DRAM
(because you intend to support mulitple Exynos SoCs)

> +and sub-blocks in SoC. Almost Exynos SoC have the common architecture

+and sub-blocks in SoC. Most Exynos SoCs share the common architecture

> +for buses. Generally, the each bus of Exynos SoC includes the source clock

+for buses. Generally, each bus of Exynos SoC includes a source clock

> +and power line and then is able to change the clock according to the usage

+and a power line, which are able to change the clock frequency 

> +of each buses on runtime. When gathering the usage of each buses on runtime,

+of the bus in runtime. To monitor the usage of each bus in runtime,

> +the driver uses the PPMU (Platform Performance Monitoring Unit) which

+the driver uses the PPMU (Platform Performance Monitoring Unit), which

> +is able to measure the current load of sub-blocks.
> +
> +There are a little different composition among Exynos SoC because each Exynos
> +SoC has the different sub-blocks. So, this difference should be specified

+SoC has different sub-blocks. Therefore, such difference should be specified

> +in devicetree file instead of each device driver. In result, this driver
> +is able to support the bus frequency for all Exynos SoCs.
> +
[]
N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf

Re: [PATCH v4 03/20] ARM: dts: Add DMC bus node for Exynos3250

[MyungJoo Ham]

>   
>  This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 
> SoC.
> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
> block.
> 
> Following list specifies the detailed relation between the clock and DMC 
> block:
> - The source clock of DMC block : div_dmc
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Acked-by: MyungJoo Ham <myungjoo@samsung.com>

N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf

Re: [PATCH v4 04/20] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk

[MyungJoo Ham]

>   
>  This patch adds the DMC (Dynamic Memory Controller) bus frequency node
> which includes the devfreq-events and regulator properties. The bus
> frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
> with ondemand governor.
> 
> The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
> on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
> the DMC block.
> 
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Acked-by: MyungJoo Ham <myungjoo@samsung.com>

Re: Re: [RFC PATCH 02/15] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[MyungJoo Ham]

> Hi Rob,
> 
> On Sat, Nov 28, 2015 at 5:30 AM, Rob Herring  wrote:
> > On Thu, Nov 26, 2015 at 10:47:26PM +0900, Chanwoo Choi wrote:
> >> This patch adds the documentation for generic exynos bus frequency
> >> driver.
> >>
> >> Signed-off-by: Chanwoo Choi 
> >> ---
> >>  .../devicetree/bindings/devfreq/exynos-bus.txt | 92 
> >> ++
> >>  1 file changed, 92 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> >> +Example2 :
> >> + The bus of DMC block in exynos3250.dtsi are listed below:
> >
> > What is DMC?
> 
> DMC (DRAM Memory Controller)

It's Dynamic Memory Controller. (DRAM =~ Dynamic Memory)

You may need to write the full name with the first reference of DMC there
in the documentation as "DMC" may confuse a lot of people.



Cheers,
MyungJoo

Re: [RFC PATCH 01/15] PM / devfreq: exynos: Add generic exynos bus frequency driver

[MyungJoo Ham]

On Thu, Nov 26, 2015 at 10:47 PM, Chanwoo Choi  wrote:
> This patch adds the generic exynos bus frequency driver for AMBA AXI bus
> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
> have the common architecture for bus between DRAM and sub-blocks in SoC.
> This driver can support the generic bus frequency driver for Exynos SoCs.
>
> In devicetree, Each bus block has a bus clock, regulator, operation-point
> and devfreq-event devices which measure the utilization of each bus block.
>
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/devfreq/Kconfig |  15 ++
>  drivers/devfreq/Makefile|   1 +
>  drivers/devfreq/exynos/Makefile |   1 +
>  drivers/devfreq/exynos/exynos-bus.c | 443 
> 
>  4 files changed, 460 insertions(+)
>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
>

Are we finally getting a common Exynos bus driver with full DT support?
(can this replace both Exynos4/5 drivers and support Exynos7 series?)


Cheers,
MyungJoo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] PM / devfreq: exynos-ppmu: fix load_count calculation

[MyungJoo Ham]

 pmcnt_high  0xff is a u32 so we shifting it 32 spaces is zero.  GCC
 catches this bug:
 
 drivers/devfreq/event/exynos-ppmu.c: In function ‘exynos_ppmu_v2_get_event’:
 drivers/devfreq/event/exynos-ppmu.c:322:3: warning: left shift count = width 
 of type
load_count = (u64)((pmcnt_high  0xff)  32) + (u64)pmcnt_low;
 
 Fixes: 3d87b02281a2 ('PM / devfreq: exynos-ppmu: Add the support of PPMUv2 
 for Exynos5433')
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

This patch has been waiting in devfreq tree for some days.
It will be sent with the next pull request.

https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/commit/?h=for-rafaelid=8e29abebbdb32a30d87a58201ac9b77f8a87fd84

 
 diff --git a/drivers/devfreq/event/exynos-ppmu.c 
 b/drivers/devfreq/event/exynos-ppmu.c
 index f9901f5..daf2cdb 100644
 --- a/drivers/devfreq/event/exynos-ppmu.c
 +++ b/drivers/devfreq/event/exynos-ppmu.c
 @@ -319,7 +319,7 @@ static int exynos_ppmu_v2_get_event(struct 
 devfreq_event_dev *edev,
   case PPMU_PMNCNT3:
   pmcnt_high = __raw_readl(info-ppmu.base + PPMU_V2_PMCNT3_HIGH);
   pmcnt_low = __raw_readl(info-ppmu.base + PPMU_V2_PMCNT3_LOW);
 - load_count = (u64)((pmcnt_high  0xff)  32) + (u64)pmcnt_low;
 + load_count = (((u64)pmcnt_high  0xff)  32) + pmcnt_low;
   break;
   }
   edata-load_count = load_count;
 

Re: Re: [PATCH] PM / devfreq: event: Remove incorrect property in exynos-ppmu DT binding

[MyungJoo Ham]

 Hello Myungjoo,
 
 On 07/23/2015 10:30 AM, Javier Martinez Canillas wrote:
  Hello Chanwoo,
 
  On 07/23/2015 10:19 AM, Chanwoo Choi wrote:
  Hi Javier,
 
  On 07/13/2015 03:58 PM, Javier Martinez Canillas wrote:
  The exynos-ppmu driver is only a clock consumer and not a clock
  provider but its Device Tree binding listed #clock-cells as an
  optional property.
 
  Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
 
[]
 
  Example1 : PPMU nodes in exynos3250.dtsi are listed below.
 
 
 
  Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
 
  + Devfreq maintainer (Myungjoo Ham)
 
  Thanks for the review and for cc'ing Myungjoo. The get_maintainer.pl script
  didn't tell me that so I think Documentation/devicetree/bindings/devfreq/
  sub-dir should be added to the DEVICE FREQUENCY (DEVFREQ) entry in the
  MAINTAINERS file.
 
  I think that this patch will be more appropriate on devfreq git tree
  than linux-samsung git tree.
 
 
  Agreed.
 
 
 Any comments about this patch?

Nope. It's applied.


Thanks.



MyungJoo

 
 
 
 Best regards,
 --
N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCH v2 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433

[MyungJoo Ham]

   
  This patch adds the support for PPMU (Platform Performance Monitoring Unit)
 version 2.0 for Exynos5433 SoC. Exynos5433 SoC must need PPMUv2 which is
 quite different from PPMUv1.1. The exynos-ppmu.c driver supports both PPMUv1.1
 and PPMUv2.
 
 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com

Acked-by: MyungJoo Ham myungjoo@samsung.com

 ---
  drivers/devfreq/event/exynos-ppmu.c | 170 
 ++--
  drivers/devfreq/event/exynos-ppmu.h |  70 +++
  2 files changed, 233 insertions(+), 7 deletions(-)
 

Re: Re: [PATCH] extcon: max77843: Clear IRQ bits state before request IRQ

[MyungJoo Ham]

   
  On 06/05/2015 01:54 PM, MyungJoo Ham wrote:

   IRQ signal before driver probe is needless because driver sends
  current state after platform booting done.
  So, this patch clears MUIC IRQ bits before request IRQ.
 
  Signed-off-by: Jaewon Kim jaewon02@samsung.com
  ---
   drivers/extcon/extcon-max77843.c |9 +
   1 file changed, 9 insertions(+)
  
  Q1. Is this because the pending bits are USELESS?
  or because the pendeing bits incurs INCORRECT behaviors?
 
 The max77843 datasheet includes following sentence:
 - All bits are cleared after a read about INT1/INT2/INT3 register.
 There are no problem about interrupt handling.
 
  
  Q2. Does clearing (by reading) INT1 do everything you need?
  What about INT2 and INT3?
 
 The MAXIM MAX77843 MUIC support the one more interrupts (e.g., ADC1K, VBVolt, 
 ChgTyp ...).
 The each interrupt is included in the one register among INT1/2/3.
 
 This patch clear the all interrupts of MAX77843 before requesting the 
 interrupts.
 
  
  Q3. I presume that driver sends current state after... is
  coming from the invokation of queue_delayed_work() at the end 
  of the probe function. It appears that you are only serving
  the pending status of cable detection with it while INT1
  seems to have more functionalities. Does that delayed work
  do everything that are pending, really?
 
 When completed kernel booting, the delayed work of extcon-max77843.c driver
 use the MAX77843_MUIC_STATUSx register to detect the type of connected
 external connectors. So, there are no problme about clearing all bits of 
 INT1/2/3 interrupt register.
 
 If user-space platform don't finish the initialization of all user-process 
 daemons
 and extcon driver send the uevent during only kernel booting, the uevent is 
 not handled
 on user-space daemons.
 
 Thanks,
 Chanwoo Choi

Ok. Looks Good. Thanks for the explanation.

Acked-by: MyungJoo Ham myungjoo@samsung.com


N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCH] extcon: max77843: Clear IRQ bits state before request IRQ

[MyungJoo Ham]

   
  IRQ signal before driver probe is needless because driver sends
 current state after platform booting done.
 So, this patch clears MUIC IRQ bits before request IRQ.
 
 Signed-off-by: Jaewon Kim jaewon02@samsung.com
 ---
  drivers/extcon/extcon-max77843.c |9 +
  1 file changed, 9 insertions(+)

Q1. Is this because the pending bits are USELESS?
or because the pendeing bits incurs INCORRECT behaviors?

Q2. Does clearing (by reading) INT1 do everything you need?
What about INT2 and INT3?

Q3. I presume that driver sends current state after... is
coming from the invokation of queue_delayed_work() at the end 
of the probe function. It appears that you are only serving
the pending status of cable detection with it while INT1
seems to have more functionalities. Does that delayed work
do everything that are pending, really?


Cheers,
MyungJoo

 
 diff --git a/drivers/extcon/extcon-max77843.c 
 b/drivers/extcon/extcon-max77843.c
 index d78a64d..11e09d1 100644
 --- a/drivers/extcon/extcon-max77843.c
 +++ b/drivers/extcon/extcon-max77843.c
 @@ -781,6 +781,15 @@ static int max77843_muic_probe(struct platform_device 
 *pdev)
   /* Support virtual irq domain for max77843 MUIC device */
   INIT_WORK(info-irq_work, max77843_muic_irq_work);
  
 + /* Clear IRQ bits before request IRQs */
 + ret = regmap_bulk_read(max77843-regmap_muic,
 + MAX77843_MUIC_REG_INT1, info-status,
 + MAX77843_MUIC_IRQ_NUM);
 + if (ret) {
 + dev_err(pdev-dev, Failed to Clear IRQ bits\n);
 + goto err_muic_irq;
 + }
 +
   for (i = 0; i  ARRAY_SIZE(max77843_muic_irqs); i++) {
   struct max77843_muic_irq *muic_irq = max77843_muic_irqs[i];
   unsigned int virq = 0;
 -- 
 1.7.9.5
 

Re: [PATCH 30/35 linux-next] devfreq: constify of_device_id array

[MyungJoo Ham]

 of_device_id is always used as const.
 (See driver.of_match_table and open firmware functions)
 
 Signed-off-by: Fabian Frederick f...@skynet.be

Acked-by: MyungJoo Ham myungjoo@samsung.com

 ---
  drivers/devfreq/event/exynos-ppmu.c | 2 +-
  drivers/devfreq/tegra-devfreq.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/devfreq/event/exynos-ppmu.c 
 b/drivers/devfreq/event/exynos-ppmu.c
 index ad83473..5afb851 100644
 --- a/drivers/devfreq/event/exynos-ppmu.c
 +++ b/drivers/devfreq/event/exynos-ppmu.c
 @@ -354,7 +354,7 @@ static int exynos_ppmu_remove(struct platform_device 
 *pdev)
   return 0;
  }
  
 -static struct of_device_id exynos_ppmu_id_match[] = {
 +static const struct of_device_id exynos_ppmu_id_match[] = {
   { .compatible = samsung,exynos-ppmu, },
   { /* sentinel */ },
  };
 diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
 index 3479096..244d8db 100644
 --- a/drivers/devfreq/tegra-devfreq.c
 +++ b/drivers/devfreq/tegra-devfreq.c
 @@ -695,7 +695,7 @@ static SIMPLE_DEV_PM_OPS(tegra_devfreq_pm_ops,
tegra_devfreq_suspend,
tegra_devfreq_resume);
  
 -static struct of_device_id tegra_devfreq_of_match[] = {
 +static const struct of_device_id tegra_devfreq_of_match[] = {
   { .compatible = nvidia,tegra124-actmon },
   { },
  };
 -- 
 2.1.0
 
 

Re: [PATCH] devfreq: event: Add 'const' keyword for devfreq_event_ops structure

[MyungJoo Ham]

   
  This patch adds the 'const' keyword for devfreq_event_ops structure
 because the ops of devfreq_event_desc structure shold not be changed
 after initialization.
 
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/devfreq/event/exynos-ppmu.c | 2 +-
  include/linux/devfreq-event.h   | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 

Merged with a little rephrasing.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com

Re: Re: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver

[MyungJoo Ham]

 Hello Chanwoo!
 
 Chanwoo Choi wrote:
  As you thought, when maintaining lower clock of memory bus frequency,
  some issue related to multimedia feature will happen.
  
  Separately, We have to check the miminum lower clock for working of 
  multimedia feature.
  and then multimedia or other IP have to request it to DVFS driver (memory 
  busfreq driver).
  But, latest mainline kernel currently has not some way to inform minimum 
  clock to DVFS driver.
  
  So, If you check the miminum clock for hdmi, I'll use this clock as minumu 
  frequency of dvfs table.
  
  Thanks,
  Chanwoo Choi
  
 
 First I have to apologize. I didn't check carefully. Actually it's not
 the HDMI subsystem which seems to hang during my test, but the G2D
 subsystem.
 
 Here's a snippet of the kernel log with drm.debug=0xff:
 [ 1157.911264] [drm:drm_framebuffer_reference] ee144e00: FB ID: 27 (2)
 [ 1157.911271] [drm:drm_framebuffer_unreference] ee37fb80: FB ID: 25 (2)
 [ 1157.911277] [drm:drm_framebuffer_unreference] ee144e00: FB ID: 27 (3)
 [ 1157.911315] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
 EXYNOS_G2D_GET_VER
 [ 1158.434439] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
 EXYNOS_G2D_SET_CMDLIST
 [ 1158.434536] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1, EXYNOS_G2D_EXEC
 [ 1158.437484] [drm:drm_vm_close_locked] 0xaf84,0x0014
 [ 1158.437507] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
 DRM_IOCTL_GEM_CLOSE
 [ 1158.437524] [drm:exynos_drm_gem_destroy] handle count = 0
 [ 1158.437532] [drm:lowlevel_buffer_deallocate] dma_addr(0x2050),
 size(0x14)
 [ 1158.437810] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
 EXYNOS_GEM_CREATE
 [ 1158.437819] [drm:exynos_drm_init_buf] desired size = 0x256000
 [ 1158.437851] [drm:exynos_drm_gem_init] created file object = 0xe97c8d00
 [ 1158.445506] [drm:lowlevel_buffer_allocate] dma_addr(0x2140),
 size(0x256000)
 [ 1158.445535] [drm:exynos_drm_gem_handle_create] gem handle = 0x1
 [ 1158.445556] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
 DRM_IOCTL_MODE_MAP_DUMB
 [ 1158.445570] [drm:exynos_drm_gem_dumb_map_offset] offset = 0x101c2000
 [ 1158.445600] [drm:drm_vm_open_locked] 0xaec15000,0x00256000
 [ 1158.445608] [drm:update_vm_cache_attr] flags = 0x0
 [ 1158.457696] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
 EXYNOS_G2D_SET_CMDLIST
 [ 1158.457745] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1, EXYNOS_G2D_EXEC
 
 
 So G2D_EXEC seems to work once, but the second time it hangs forever. I
 even fail at attaching gdb to the application then (gdb then also hangs
 in D state).
 
 If I just use the 'vsynced page flipping' test, then everything works:
 ./modetest -M exynos -s 16@13:1280x720 -v
 setting mode 1280x720-60Hz@XR24 on connectors 16, crtc 13
 freq: 61.08Hz
 freq: 60.00Hz
 freq: 60.00Hz
 etc.
 
 I'm going to do some tests with the G2D in the next time, checking how
 much I can lower MIF/INT clocks before the engine becomes unstable.
 
 With best wishes,
 Tobias
 
 

Unless you are willing to wait for 2 minutes after the kernal hangs,
you may want to adjust DEFAULT_HUNG_TASK_TIMEOUT to shorter value
(120 -- 5 for 5 seconds). It seems that you've cut it off in the middle
of that 120 sec wait.

If it's in D state (in kernel), gdb won't work as you are experiencing.
Sorry for not testing with HDMI; my Exynos devices do not have HDMI. :)

To Chanwoo, wouldn't it be ok to have the corresponding devfreq driver
to set minimum higher IFF HDMI is enabled? (either by build time or
run time) I guess Exynos HDMI driver should express PM-QoS requests later.
(Or let Exynos HDMI driver not hung even if its memory transactions are
not fast enough)

Cheers,
MyungJoo

Re: Re: [patch] PM / devfreq: event: testing the wrong variable

[MyungJoo Ham]

   
  On 02/10/2015 07:35 PM, Dan Carpenter wrote:
  There is a typo here so we test edev but we intended to test
  edev[i].
  
  Fixes: f262f28c1470 ('PM / devfreq: event: Add devfreq_event class')
  Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
  
  diff --git a/drivers/devfreq/event/exynos-ppmu.c 
  b/drivers/devfreq/event/exynos-ppmu.c
  index 135be0a..ad83473 100644
  --- a/drivers/devfreq/event/exynos-ppmu.c
  +++ b/drivers/devfreq/event/exynos-ppmu.c
  @@ -327,8 +327,8 @@ static int exynos_ppmu_probe(struct platform_device 
  *pdev)
  -   if (IS_ERR(edev)) {
  -   ret = PTR_ERR(edev);
  +   if (IS_ERR(edev[i])) {
  +   ret = PTR_ERR(edev[i]);
 
 Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
 
 But,
 This patch has not yet merged to linux.git 
 (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git).
 After releasing Linux 3.20-rc1, this patch will be handled.
 
 Thanks,
 Chanwoo Choi

Acked-by: MyungJoo Ham myungjoo@samsung.com

Re: RE: [PATCH v9 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device

[MyungJoo Ham]

   
  Chanwoo Choi wrote:
  
 Hi,
 

[]

  
  --
 
 Looks good to me.
 
 Myungjoo, shall I take DT changes in this series into Samsung tree?
 
 4/7 ARM: dts: Add PPMU dt node for Exynos3250 SoC
 5/7 ARM: dts: Add PPMU dt node for Exynos4 SoCs
 6/7 ARM: dts: exynos: Add PPMU node for Exynos3250-based Rinato/Monk board
 7/7 ARM: dts: exynos: Add PPMU node for Exynos4412-based TRATS2 board

Yes, you may take those. I am not so confident with taking DT patches, either.

However, Chanwoo has another updates following for this patchset.

After that, I guess we can merge chanwoo's patchset splitted.



Cheers,
MyungJoo.

 
 Thanks,
 Kukjin
 

Re: [PATCHv8 1/9] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor

[MyungJoo Ham]

   
  This patch add new devfreq_event class for devfreq_event device which provide
 raw data (e.g., memory bus utilization/GPU utilization). This raw data from
 devfreq_event data would be used for the governor of devfreq subsystem.
 - devfreq_event device : Provide raw data for governor of existing devfreq 
 device
 - devfreq device   : Monitor device state and change frequency/voltage of 
 device
  using the raw data from devfreq_event device
 
 The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling)
 for Non-CPU Devices. The devfreq device would dertermine current device state
 using various governor (e.g., ondemand, performance, powersave). After 
 completed
 determination of system state, devfreq device would change the 
 frequency/voltage
 of devfreq device according to the result of governor.
 
 But, devfreq governor must need basic data which indicates current device 
 state.
 Existing devfreq subsystem only consider devfreq device which check current 
 system
 state and determine proper system state using basic data. There is no 
 subsystem
 for device providing basic data to devfreq device.
 
 The devfreq subsystem must need devfreq_event device(data-provider device) for
 existing devfreq device. So, this patch add new devfreq_event class for
 devfreq_event device which read various basic data(e.g, memory bus 
 utilization,
 GPU utilization) and provide measured data to existing devfreq device through
 standard APIs of devfreq_event class.
 
 The following description explains the feature of two kind of devfreq class:
 - devfreq class (existing)
  : devfreq consumer device use raw data from devfreq_event device for
determining proper current system state and change voltage/frequency
dynamically using various governors.
 
 - devfreq_event class (new)
  : Provide measured raw data to devfreq device for governor
 
 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---

[]

 +/**
 + * devfreq_event_enable_edev() - Enable the devfreq-event dev and increase
 + *the enable_count of devfreq-event dev.
 + * @edev : the devfreq-event device
 + *
 + * Note that this function increase the enable_count and enable the
 + * devfreq-event device. The devfreq-event device should be enabled before
 + * using it by devfreq device.
 + */
 +int devfreq_event_enable_edev(struct devfreq_event_dev *edev)
 +{
 + int ret = 0;
 +
 + if (!edev || !edev-desc)
 + return -EINVAL;
 +
 + mutex_lock(edev-lock);
 + if (edev-desc-ops  edev-desc-ops-enable) {
 + ret = edev-desc-ops-enable(edev);
 + if (ret  0)
 + goto err;
 + }

Is there any reason to call enable(edev) even when enable_count is already  0 
while you do not call disable(edev) while enable_count  0?

I think this may incur errors in the related device drivers.
(e.g., incorrect pairing of clk/runtime-pm/regulator enable/disable
at the device driver side)

 + edev-enable_count++;
 +err:
 + mutex_unlock(edev-lock);
 +
 + return ret;
 +}
 +EXPORT_SYMBOL_GPL(devfreq_event_enable_edev);
 +
 +/**
 + * devfreq_event_disable_edev() - Disable the devfreq-event dev and decrease
 + * the enable_count of the devfreq-event dev.
 + * @edev : the devfreq-event device
 + *
 + * Note that this function decrease the enable_count and disable the
 + * devfreq-event device. After the devfreq-event device is disabled,
 + * devfreq device can't use the devfreq-event device for get/set/reset
 + * operations.
 + */
 +int devfreq_event_disable_edev(struct devfreq_event_dev *edev)
 +{
 + int ret = 0;
 +
 + if (!edev || !edev-desc)
 + return -EINVAL;
 +
 + mutex_lock(edev-lock);
 + if (edev-enable_count  0) {
 + edev-enable_count--;
 + } else {
 + dev_warn(edev-dev, unbalanced enable_count\n);
 + ret = -EINVAL;
 + goto err;
 + }
 +
 + if (edev-desc-ops  edev-desc-ops-disable) {
 + ret = edev-desc-ops-disable(edev);
 + if (ret  0) {
 + edev-enable_count++;
 + goto err;
 + }
 + }

You did it correctly with disable here;
not calling it when it is not required.

 +err:
 + mutex_unlock(edev-lock);
 +
 + return ret;
 +}
 +EXPORT_SYMBOL_GPL(devfreq_event_disable_edev);
 +

[]
 +EXPORT_SYMBOL_GPL(devfreq_event_is_enabled);
[]

 +EXPORT_SYMBOL_GPL(devfreq_event_set_event);
[]

 +
 +/**
 + * devfreq_event_get_event() - Get event and total_event from devfreq-event 
 dev.
 + * @edev : the devfreq-event device
 + * @edata: the calculated data of devfreq-event device
 + *
 + * Note that this function get the calculated event data from devfreq-event 
 dev
 + * after stoping the progress of whole sequence of devfreq-event dev

Re: [PATCHv8 2/9] devfreq: event: Add resource-managed function for devfreq-event device

[MyungJoo Ham]

   
  This patch add the resource-managed function for devfreq-event device as
 following functions. The devm_devfreq_event_add_edev() manages automatically
 the memory of devfreq-event device using resource management.
 - devm_devfreq_event_add_edev()
 - devm_devfreq_event_remove_edev()
 
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.coma

Reviewed-by: MyungJoo Ham myungjoo@samsung.com

You may merge this patch with 1/9 as well.
I don't think this is a major change the requires a seperated patch.


Cheers,
MyungJoo
N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCH v4 8/9] ARM: dts: Add the support for exynos busfreq on Exynos4412-based TRATS2 board

[MyungJoo Ham]

   
  This patch adds the Exynos4412 memory-bus node which includes the regulator
 and devfreq-event phandle. The devfreq-event phandle is used for the
 governor of devfreq device and provide the current usage state of
 MIF (Memory Interface) / INT (Internal) memory bus group.
 
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com

Acked-by: MyungJoo Ham myungjoo@samsung.com


N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCH v4 7/9] ARM: dts: Add the support for exynos busfreq on Exynos3250-based Rinato/Monk board

[MyungJoo Ham]

   
  This patch adds the Exynos3250 memory-bus node which includes the regulator
 and devfreq-event phandle. The devfreq-event phandle is used for the
 governor of devfreq device and provide the current usage state of
 MIF (Memory Interface) / INT (Internal) memory bus group.
 
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Youngjun Cho yj44@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com

I am not so confident with this SoC as I didn't write any kernel codes
for Exynos3250 devices. Anyway, as the syntax and usage appears good to me.

Acked-by: MyungJoo Ham myungjoo@samsung.com

 ---
  arch/arm/boot/dts/exynos3250-monk.dts   | 12 
  arch/arm/boot/dts/exynos3250-rinato.dts | 12 
  2 files changed, 24 insertions(+)
 
N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCH v4 9/9] devfreq: exynos: Remove unused exynos4 memory busfreq driver

[MyungJoo Ham]

   
  This patch removes the unused exynos4 memory busfreq driver by adding generic
 exynos memory bus frequency driver.
 
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com

Reviewed-by: MyungJoo Ham myungjoo@samsung.com

 ---
  drivers/devfreq/Kconfig  |   12 -
  drivers/devfreq/exynos/Makefile  |1 -
  drivers/devfreq/exynos/exynos4_bus.c | 1055 
 --
  drivers/devfreq/exynos/exynos4_bus.h |  110 
  4 files changed, 1178 deletions(-)
  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
 

Re: [PATCH v4 6/9] ARM: dts: Add memory bus node for Exynos4210

[MyungJoo Ham]

   
  This patch adds the memory bus node for Exynos4210 SoC. Exynos4210 SoC has
 one memory bus to translate data between DRAM and eMMC/sub-IPs because
 Exynos4210 must need only one regulator for memory bus.
 
 Following list specifies the detailed relation between memory bus clock and
 sub-IPs:
 - DMC/ACP clock : DMC (Dynamic Memory Controller)
 - ACLK200 clock : LCD0
 - ACLK100 clock : PERIL/PERIR/MFC(PCLK)
 - ACLK160 clock : CAM/TV/LCD0/LCD1
 - ACLK133 clock : FSYS/GPS
 - GDL/GDR clock : leftbus/rightbus
 - SCLK_MFC clock : MFC
 
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com

Acked-by: MyungJoo Ham myungjoo@samsung.com


Revisiting good old days..?
(good to see the first busfreq driver experimented with is
being DT-nized... :)  )


Cheers,
MyungJoo

Re: Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver

[MyungJoo Ham]

Acked-by: MyungJoo Ham myungjoo@samsung.com


Adding to Chanwoo's reply:

If I understand Chanwoo's intention correctly,
this patchset is to provide a common bus  memory-interface DVFS driver
for several Exynos SoCs, which allows DT to express per-SoC hardware
details so that we do not need to hardcode them with seperated drivers
(as it is now) or a driver with a lot of unused definitions (partly
as it is now).

Having that many looking ugly frequency definitions is
because Exynos SoCs that I've seen until today have many
on-SoC IPs that should change configurations (usually clock speed)
according to the clock speed of bus. Thus, they may look
duplicated.

We may hide such details IF we make one driver per SoC model; however,
it is very inefficient with DT supported kernels if we can write
such details in DTS and make the driver simple and unified.



Cheers,
MyungJoo.

  
 Hi Rob,

First of all, thanks for your review.

On 01/09/2015 06:18 AM, Rob Herring wrote:
 Adding Viresh.
 
 On Wed, Jan 7, 2015 at 7:40 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patch adds the documentation for generic exynos memory bus frequency
 driver.

 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Kukjin Kim kg...@kernel.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  .../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 
 +
  1 file changed, 184 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt

Re: Re: [PATCHv3 1/8] devfreq: exynos: Add generic exynos memory bus frequency driver

[MyungJoo Ham]

  
 Dear Myungjoo,

On 01/13/2015 05:42 PM, MyungJoo Ham wrote:
   
  This patch adds the generic exynos bus frequency driver for memory bus
 with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
 for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
 support the memory bus frequency driver for Exynos SoCs.

 Each memory bus block has a clock for memory bus speed and frequency
 table which is changed according to the utilization of memory bus on 
 runtime.
 And then each memory bus group has the one more memory bus blocks and
 OPP table (including frequency and voltage), regulator, devfreq-event
 devices.

 There are a little difference about the number of memory bus because each 
 Exynos
 SoC have the different sub-IP and different memory bus speed. In spite of 
 this
 difference among Exynos SoCs, we can support almost Exynos SoC by adding
 unique data of memory bus to devicetree file.

 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Kukjin Kim kg...@kernel.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/devfreq/Kconfig  |  15 +
  drivers/devfreq/Makefile |   1 +
  drivers/devfreq/exynos-busfreq.c | 589 
 +++
  3 files changed, 605 insertions(+)
  create mode 100644 drivers/devfreq/exynos-busfreq.c
 
 Exynos drivers are located at drivers/devfreq/exynos/
 Please relocate/rename exynos-busfreq.c

OK. I'll move it at drivers/devfreq/exynos directory.
Do you prefer 'exynos-bus.c' instead of 'exynos-busfreq.c'?
If you reply, I'll change it.

exynos-bus looks more pretty :)


 
 []
 
 diff --git a/drivers/devfreq/exynos-busfreq.c 
 b/drivers/devfreq/exynos-busfreq.c
 new file mode 100644
 index 000..b180f43
 --- /dev/null
 +++ b/drivers/devfreq/exynos-busfreq.c
 
 []
 
 +
 +#define BUS_SATURATION_RATIO   40
 
 In order to be a common driver, this should be tunable.
 
 Because .dts is supposed to have hardware configuration only,
 you may keep a table of { chip-name, saturation ratio} in this
 driver and look up the saturation ratio based on the chip-name.

OK, I'll add new property for saturation_ratio.

I'll implement to use default saturation_ratio value ,
if dt node don't include saturation_ratio property.

Yes. I didn't talk with DT maintainers and I do not have much
experience with DT; however, it appears that such values are not
recommended to be in DTS files and this value is determined by
the SoC model number without complications in the driver file.

Re: [PATCHv3 3/8] ARM: dts: Add memory bus node for Exynos3250

[MyungJoo Ham]

   
  This patch adds the memory bus node for Exynos3250 SoC. Exynos3250 has
 following memory buses to translate data between DRAM and eMMC/sub-IPs.
 
 Following list specifies the detailed relation between memory bus clock and 
 DMC
 IP in MIF (Memory Interface) block:
 - DMC clock : DMC (Dynamic Memory Controller)
 
 Following list specifies the detailed relation between memory bus clock and
 sub-IPs in INT (Internal) block:
 - ACLK100 clock : PERIL
 - ACLK160 clock : LCD0
 - ACLK200 clock : FSYS
 - ACLK266 clock : ISP
 - GDL/GDR clock : leftbus/rightbus
 - SCLK_MFC clock : MFC
 
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com

Acked-by: MyungJoo Ham myungjoo@samsung.com



 ---
  arch/arm/boot/dts/exynos3250.dtsi | 125 
 ++
  1 file changed, 125 insertions(+)
 
N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCHv3 1/8] devfreq: exynos: Add generic exynos memory bus frequency driver

[MyungJoo Ham]

   
  This patch adds the generic exynos bus frequency driver for memory bus
 with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
 for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
 support the memory bus frequency driver for Exynos SoCs.
 
 Each memory bus block has a clock for memory bus speed and frequency
 table which is changed according to the utilization of memory bus on runtime.
 And then each memory bus group has the one more memory bus blocks and
 OPP table (including frequency and voltage), regulator, devfreq-event
 devices.
 
 There are a little difference about the number of memory bus because each 
 Exynos
 SoC have the different sub-IP and different memory bus speed. In spite of this
 difference among Exynos SoCs, we can support almost Exynos SoC by adding
 unique data of memory bus to devicetree file.
 
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Kukjin Kim kg...@kernel.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/devfreq/Kconfig  |  15 +
  drivers/devfreq/Makefile |   1 +
  drivers/devfreq/exynos-busfreq.c | 589 
 +++
  3 files changed, 605 insertions(+)
  create mode 100644 drivers/devfreq/exynos-busfreq.c

Exynos drivers are located at drivers/devfreq/exynos/
Please relocate/rename exynos-busfreq.c

[]

 diff --git a/drivers/devfreq/exynos-busfreq.c 
 b/drivers/devfreq/exynos-busfreq.c
 new file mode 100644
 index 000..b180f43
 --- /dev/null
 +++ b/drivers/devfreq/exynos-busfreq.c

[]

 +
 +#define BUS_SATURATION_RATIO 40

In order to be a common driver, this should be tunable.

Because .dts is supposed to have hardware configuration only,
you may keep a table of { chip-name, saturation ratio} in this
driver and look up the saturation ratio based on the chip-name.

 +#define SAFEVOLT 5
 +
 +struct exynos_memory_bus_opp_info {
 + unsigned long rate;
 + unsigned long volt;
 +};
 +
 +struct exynos_memory_bus_block {
 + struct clk *clk;
 + struct exynos_memory_bus_opp_info *freq_table;
 +};
 +

[]

 +#ifdef CONFIG_PM_SLEEP
 +static int exynos_busfreq_resume(struct device *dev)
 +{
 + struct exynos_memory_bus_data *data = dev_get_drvdata(dev);
 + int ret;
 +
 + ret = exynos_busfreq_enable_edev(data);
 + if (ret  0) {
 + dev_err(dev, failed to enable the devfreq-event devices\n);
 + return ret;
 + }
 +
 + return 0;
 +}
 +
 +static int exynos_busfreq_suspend(struct device *dev)
 +{
 + struct exynos_memory_bus_data *data = dev_get_drvdata(dev);
 + int ret;
 +
 + ret = exynos_busfreq_disable_edev(data);
 + if (ret  0) {
 + dev_err(dev, failed to disable the devfreq-event devices\n);
 + return ret;
 + }
 +
 + return 0;
 +}
 +#endif

Please disable regulator at suspend and resume it at resume.

You may interfere with low-power mode of corresponding voltage line,
which is often implemented to be activated if the regulator is
explicitely disabled for alive regulators like this one.

 +
 +static const struct dev_pm_ops exynos_busfreq_pm = {
 + SET_SYSTEM_SLEEP_PM_OPS(exynos_busfreq_suspend, exynos_busfreq_resume)
 +};
 +
 +static const struct of_device_id exynos_busfreq_of_match[] = {
 + { .compatible = samsung,exynos-memory-bus, },
 + { /* sentinel */ },
 +};
 +MODULE_DEVICE_TABLE(of, exynos_busfreq_of_match);
 +
 +static struct platform_driver exynos_busfreq_platdrv = {
 + .probe  = exynos_busfreq_probe,
 + .remove = exynos_busfreq_remove,
 + .driver = {
 + .name   = exynos-memory-bus,
 + .owner  = THIS_MODULE,
 + .pm = exynos_busfreq_pm,
 + .of_match_table = of_match_ptr(exynos_busfreq_of_match),
 + },
 +};
 +module_platform_driver(exynos_busfreq_platdrv);
 +
 +MODULE_DESCRIPTION(Generic Exynos Memory Bus Frequency driver);
 +MODULE_AUTHOR(Chanwoo Choi cw00.c...@samsung.com);
 +MODULE_LICENSE(GPL v2);
 -- 
 1.8.5.5
 
 

Re: [PATCHv3 5/8] ARM: dts: Add memory bus node for Exynos4x12

[MyungJoo Ham]

   
  This patch adds the memory bus node for Exynos4x12 SoC. Exynos4x12 SoC has
 two memory bus to translate data between DRAM and eMMC/sub-IPs.
 
 Following list specifies the detailed relation between memory bus clock and 
 DMC
 IP in MIF (Memory Interface) block:
 - DMC/ACP clock : DMC (Dynamic Memory Controller)
 
 Following list specifies the detailed relation between memory bus clock and
 sub-IPs in INT (Internal) block:
 - ACLK100 clock : PERIL/PERIR/MFC(PCLK)
 - ACLK160 clock : CAM/TV/LCD
 - ACLK133 clock : FSYS
 - GDL/GDR clock : leftbus/rightbus
 - SCLK_MFC clock : MFC
 
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com

Acked-by: MyungJoo Ham myungjoo@samsung.com for all the other dts file 
patch with Exynos*.


Off Topic. Not urgent. Just out of curiousity:
  Do you have some idea on how to express voltage variations
with device tree? (not runtime-AVS, but boottime-AVS. runtime-AVS is rather
trivial)

  I think you remember that we often had multiple set of OPP tables and
we chose one of them based on the value extracted at boot time in order to
use lower voltage values without deteriorating the reliability.

  Basically, such a feature requires to express multiple OPP lists and let
the kernel choose one of the lists at the boot time, which I doubt the
expressiveness in the current device tree technique.

 ---
  arch/arm/boot/dts/exynos4x12.dtsi | 121 
 ++
  1 file changed, 121 insertions(+)
 

Re: [PATCHv7 04/10] devfreq: event: Add exynos-ppmu devfreq-event driver

[MyungJoo Ham]

   
  This patch adds exynos-ppmu devfreq-event driver to get performance data
 of each IP for Samsung Exynos SoC. These event from Exynos PPMU provide
 useful information about the behavior of the SoC that you can use when
 analyzing system performance, and made visible and can be counted using
 logic in each IP.
 
 This patch is based on existing drivers/devfreq/exynos/exynos-ppmu.c
 
 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/devfreq/event/Kconfig   |   9 +
  drivers/devfreq/event/Makefile  |   1 +
  drivers/devfreq/event/exynos-ppmu.c | 399 
 
  3 files changed, 409 insertions(+)
  create mode 100644 drivers/devfreq/event/exynos-ppmu.c
 

Acked-by: MyungJoo Ham myungjoo@samsung.com

Re: [PATCHv7 03/10] devfreq: event: Add resource-managed function for devfreq-event device

[MyungJoo Ham]

   
  This patch add the resource-managed function for devfreq-event device as
 following functions. The devm_devfreq_event_add_edev() manages automatically
 the memory of devfreq-event device using resource management.
 - devm_devfreq_event_add_edev()
 - devm_devfreq_event_remove_edev()
 
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/devfreq/devfreq-event.c | 63 
 +
  include/linux/devfreq-event.h   | 16 +++
  2 files changed, 79 insertions(+)
 
 diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
 index 64c1764..5301e2b 100644
 --- a/drivers/devfreq/devfreq-event.c
 +++ b/drivers/devfreq/devfreq-event.c
 @@ -451,6 +451,69 @@ int devfreq_event_remove_edev(struct devfreq_event_dev 
 *edev)
  }
  EXPORT_SYMBOL_GPL(devfreq_event_remove_edev);
  
 +static int devm_devfreq_event_match(struct device *dev, void *res, void 
 *data)
 +{
 + struct devfreq_event_dev **r = res;
 +
 + if (WARN_ON(!r || !*r))
 + return 0;
 +
 + return *r == data;
 +}
 +
 +static void devm_devfreq_event_release(struct device *dev, void *res)
 +{
 + devfreq_event_remove_edev(*(struct devfreq_event_dev **)res);
 +}

Isn't dev-free functions supposed to check if it is already freed or not?

 +
 +/**
 + * devm_devfreq_event_add_edev() - Resource-managed devfreq_event_add_edev()
 + * @dev  : the device owning the devfreq-event device being 
 created
 + * @desc : the devfreq-event device's decriptor which include essential
 + * data for devfreq-event device.
 + *
 + * Note that this function manages automatically the memory of devfreq-event
 + * device using device resource management and simplify the free operation
 + * for memory of devfreq-event device.
 + */
 +struct devfreq_event_dev *devm_devfreq_event_add_edev(struct device *dev,
 + struct devfreq_event_desc *desc)
 +{
 + struct devfreq_event_dev **ptr, *edev;
 +
 + ptr = devres_alloc(devm_devfreq_event_release, sizeof(*ptr), 
 GFP_KERNEL);
 + if (!ptr)
 + return ERR_PTR(-ENOMEM);
 +
 + edev = devfreq_event_add_edev(dev, desc);
 + if (IS_ERR(edev)) {
 + devres_free(ptr);
 + return ERR_PTR(-ENOMEM);
 + }
 +
 + *ptr = edev;
 + devres_add(dev, ptr);
 +
 + return edev;
 +}
 +EXPORT_SYMBOL(devm_devfreq_event_add_edev);

You are using GPL Symbol in this function (devres_alloc).

 +
 +/**
 + * devm_devfreq_event_remove_edev()- Resource-managed 
 devfreq_event_remove_edev()
 + * @dev  : the device owning the devfreq-event device being 
 created
 + * @edev : the devfreq-event device
 + *
 + * Note that this function manages automatically the memory of devfreq-event
 + * device using device resource management.
 + */
 +void devm_devfreq_event_remove_edev(struct device *dev,
 + struct devfreq_event_dev *edev)
 +{
 + WARN_ON(devres_release(dev, devm_devfreq_event_release,
 +devm_devfreq_event_match, edev));
 +}
 +EXPORT_SYMBOL(devm_devfreq_event_remove_edev);

Here you are using GPL symbol as well (devres_release).

[]

Re: [PATCHv7 10/10] ARM: dts: exynos: Add PPMU node for Exynos4412-based TRATS2 board

[MyungJoo Ham]

  This patch add dt node for PPMU_{DMC0|DMC1|LEFTBUS|RIGHTBUS} for
 exynos4412-trats2 board. Each PPMU dt node includes one event of 'PPMU 
 Count3'.
 
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Myungjoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  arch/arm/boot/dts/exynos4412-trats2.dts | 40 
 +
  1 file changed, 40 insertions(+)


Acked-by: MyungJoo Ham myungjoo@samsung.com

I didn't review 5260, Rinato, and Monk as I am not familiar with those.

Cheers,
MyungJoo

N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCHv7 05/10] devfreq: event: Add documentation for exynos-ppmu devfreq-event driver

[MyungJoo Ham]

I have rephrased part of the documentation for better readability.
Some semantics is guessed so you may need to re-rephrase.

Other than that, Acked-by: MyungJoo Ham myungjoo@samsung.com


  This patch adds the documentation for Exynos PPMU (Platform Performance
 Monitoring Unit) devfreq-event driver.
 
 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  .../bindings/devfreq/event/exynos-ppmu.txt | 110 
 +
  1 file changed, 110 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
 
 diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt 
 b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
 new file mode 100644
 index 000..e665d30
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
 @@ -0,0 +1,110 @@
 +
 +* Samsung Exynos PPMU (Performance Profiling Monitoring Unit) device
 +
 +The Samsung Exynos SoC have PPMU (Performance Profiling Monitoring Unit) for

The Samsung Exynos SoC has PPMU (Performance Profiling Monitoring Unit) for
(have-has)

 +each IPs. PPMU provides the primitive values to get performance data. These

each IP. PPMU provides primitive values to get performance data.
(IPs-IP)

 +events provide useful information about the behavior of the SoC that you can

PPMU events provide information of the SoC's behaviors so that you may

 +use when analyzing system performance, and made visible and can be counted

use to analyze system performance, to make behaviors visible, and to count

 +using login in each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D,

usages of each IP (  )

 +MFC). The Exynos PPMU driver use the devfreq-event class to provide event 
 data

use - uses

 +to various devfreq device. The devfreq device would use the event data when

device - devices

 +derterming the current state of each IP.
 +
 +Required properties:
 +- compatible: Should be samsung,exynos-ppmu.
 +- reg: physical base address of each PPMU and length of memory mapped region.
 +
 +Optional properties:
 +- clock-names : the name of clock used by the PPMU, ppmu
 +- clocks : phandles for clock specified in clock-names property
 +- #clock-cells: should be 1.
 +

[]
N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCHv7 07/10] ARM: dts: Add PPMU dt node for Exynos4 SoCs

[MyungJoo Ham]

   
  This patch add PPMU (Platform Performance Monitoring Unit) dt node for 
 Exynos4
 (Exynos4210/4212/4412) SoC. PPMU dt node is used to monitor the utilization of
 each IP.
 
 The Exynos4210/Exynos4212/Exynos4412 SoC includes following PPMUs:
 - PPMU_DMC0  0x106A_
 - PPMU_DMC1  0x106B_
 - PPMU_CPU   0x106C_
 - PPMU_ACP   0x10AE_
 - PPMU_RIGHT_BUS 0x112A_
 - PPMU_LEFT_BUS  0x116A_
 - PPMU_FSYS  0x1263_
 - PPMU_LCD0  0x11E4_
 - PPMU_CAMIF 0x11AC_
 - PPMU_IMAGE 0x12AA_
 - PPMU_TV0x12E4_
 - PPMU_3D0x1322_
 - PPMU_MFC_LEFT  0x1366_
 - PPMU_MFC_RIGHT 0x1367_
 
 Additionally, the Exynos4210 SoC includes following PPMUs:
 - PPMU_LCD1  0x1224_
 
 Cc: Kukjin Kim kg...@kernel.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  arch/arm/boot/dts/exynos4.dtsi| 108 
 ++
  arch/arm/boot/dts/exynos4210.dtsi |   8 +++
  2 files changed, 116 insertions(+)
 

Acked-by: MyungJoo Ham myungjoo@samsung.com

Re: [PATCHv7 00/10] devfreq: Add devfreq-event class to provide raw data for devfreq device

[MyungJoo Ham]

   
  This patchset add new devfreq_event class to provide raw data to determine
 current utilization of device  which is used for devfreq governor.
 
 The following description explains the feature of two kind of devfreq class:
 - devfreq class (existing)
  : devfreq consumer device use raw data from devfreq_event device for
determining proper current system state and change voltage/frequency
dynamically using various governors.
 - devfreq_event class (new)
  : Provide measured raw data to devfreq device for governor
 

Question: Applying this patchset seems to imply that
drivers/devfreq/exynos/exynos_ppmu.c becomes obsolete.
How do you want to address it? Do you think it'd be ok to remove
thse obsolete drivers after your successing patchset?

If it is ok to remove old drivers after applying the new patchset,
please inclde a patch that removes old drivers unless such a removal
might result in compatibility issues with old (yet another obsolete)
board files, which I don't think probable.


Cheers,
MyungJoo.

N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: Re: [PATCHv7 00/10] devfreq: Add devfreq-event class to provide raw data for devfreq device

[MyungJoo Ham]

  
 On 01/12/2015 06:58 PM, MyungJoo Ham wrote:
   
  This patchset add new devfreq_event class to provide raw data to determine
 current utilization of device  which is used for devfreq governor.

 The following description explains the feature of two kind of devfreq class:
 - devfreq class (existing)
  : devfreq consumer device use raw data from devfreq_event device for
determining proper current system state and change voltage/frequency
dynamically using various governors.
 - devfreq_event class (new)
  : Provide measured raw data to devfreq device for governor

 
 Question: Applying this patchset seems to imply that
 drivers/devfreq/exynos/exynos_ppmu.c becomes obsolete.
 How do you want to address it? Do you think it'd be ok to remove
 thse obsolete drivers after your successing patchset?
 
 If it is ok to remove old drivers after applying the new patchset,
 please inclde a patch that removes old drivers unless such a removal
 might result in compatibility issues with old (yet another obsolete)
 board files, which I don't think probable.

I agree to remove 'drviers/devfreq/exynos/exynos_ppmu.c.
But, existing exynos_ppmu.c was used for drivers/devfreq/exynos/exynos5_bus.c.

Before removing existing 'exynos_ppmu.c', might need to test the devfreq-event 
class
on Exynos5260 SoC. I will just remove old 
driver('drivers/devfreq/exynos/exynos4_bus.{c|h}')
on next patchset.

That's fine with me.


Cheers,
MyungJoo


To Abhilash,
Could you test this patch-set on Exynos5260 SoC?

Best Regards,
Chanwoo Choi

Re: [PATCHv7 02/10] devfreq: event: Add the list of supported devfreq-event type

[MyungJoo Ham]

   
  This patch adds the list of supported devfreq-event type as following.
 Each devfreq-event device driver would support the various devfreq-event type
 for devfreq governor at the same time.
 - DEVFREQ_EVENT_TYPE_RAW_DATA
 - DEVFREQ_EVENT_TYPE_UTILIZATION
 - DEVFREQ_EVENT_TYPE_BANDWIDTH
 - DEVFREQ_EVENT_TYPE_LATENCY

Did you try to say:

A devfreq-event device may support multiple devfreq-event types
simultaneously.

If so, your switch expressions are going to screw up.


 
 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/devfreq/devfreq-event.c | 58 
 -
  include/linux/devfreq-event.h   | 25 +++---
  2 files changed, 73 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
 index 81448ba..64c1764 100644
 --- a/drivers/devfreq/devfreq-event.c
 +++ b/drivers/devfreq/devfreq-event.c
  
[]
 - mutex_lock(edev-lock);
 - ret = edev-desc-ops-get_event(edev, edata);
 - mutex_unlock(edev-lock);
 + switch (type) {

Bitwise value with switch? (what if type = RAW_DATA | BANDWIDTH, meaning
this is raw data of the bandwitdh.)

 + case DEVFREQ_EVENT_TYPE_RAW_DATA:
 + case DEVFREQ_EVENT_TYPE_BANDWIDTH:
 + case DEVFREQ_EVENT_TYPE_LATENCY:
 + if ((edata-event  EVENT_TYPE_RAW_DATA_MAX) ||
 + (edata-total_event  EVENT_TYPE_RAW_DATA_MAX)) {

Is it possible for unsigned long edata-event/total_event to be
   EVENT_TYPE_RAW_DATA_MAX = ULONG_MAX?

What was your intention?

If you were trying to detect overflow, you need to rethink about it.
If not, (overflow is harmless or not going to happen) you don't need to
check it.


 + edata-event = edata-total_event = 0;
 + ret = -EINVAL;
 + }
 + break;
 + case DEVFREQ_EVENT_TYPE_UTILIZATION:
 + edata-total_event = EVENT_TYPE_UTILIZATION_MAX;
  
 - if ((edata-total_event = 0)
 - || (edata-event  edata-total_event)) {
 + if (edata-event  EVENT_TYPE_UTILIZATION_MAX) {
 + edata-event = edata-total_event = 0;
 + ret = -EINVAL;
 + }
 + break;
 + default:
   edata-event = edata-total_event = 0;
   ret = -EINVAL;
 + break;
   }
  
 + mutex_unlock(edev-lock);
 +
   return ret;
  }
  EXPORT_SYMBOL_GPL(devfreq_event_get_event);
 diff --git a/include/linux/devfreq-event.h b/include/linux/devfreq-event.h
 index b7363f5..13a5703 100644
 --- a/include/linux/devfreq-event.h
 +++ b/include/linux/devfreq-event.h
 @@ -36,6 +36,14 @@ struct devfreq_event_dev {
   const struct devfreq_event_desc *desc;
  };
  
 +/* The supported type by devfreq-event device */
 +enum devfreq_event_type {
 + DEVFREQ_EVENT_TYPE_RAW_DATA = BIT(0),
 + DEVFREQ_EVENT_TYPE_UTILIZATION  = BIT(1),
 + DEVFREQ_EVENT_TYPE_BANDWIDTH= BIT(2),
 + DEVFREQ_EVENT_TYPE_LATENCY  = BIT(3),
 +};
 +

(Being curious) Is it possible to have multiple types
simultaneously?


[]
N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: Re: [PATCHv4 1/8] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor

[MyungJoo Ham]

   
  Dear Myungjoo,
 
 Thanks for your review.
 
 On 12/18/2014 03:24 PM, MyungJoo Ham wrote:
  Hi Chanwoo,
  
  I love the idea and I now have a little mechanical issues in your code.
  
  ---
   drivers/devfreq/Kconfig |   2 +
   drivers/devfreq/Makefile|   5 +-
   drivers/devfreq/devfreq-event.c | 449 
  
   drivers/devfreq/event/Makefile  |   1 +
   include/linux/devfreq.h | 160 ++
   5 files changed, 616 insertions(+), 1 deletion(-)
   create mode 100644 drivers/devfreq/devfreq-event.c
   create mode 100644 drivers/devfreq/event/Makefile
 

[]

 
  
  
  [snip]
  
  diff --git a/drivers/devfreq/devfreq-event.c 
  b/drivers/devfreq/devfreq-event.c
  new file mode 100644
  index 000..0e1948e
  --- /dev/null
  +++ b/drivers/devfreq/devfreq-event.c
  @@ -0,0 +1,449 @@
  +/*
  + * devfreq-event: Generic DEVFREQ Event class driver
  
  DEVFREQ is a generic DVFS mechanism (or subsystem).
  
  Plus, I thought devfreq-event is considered to be a framework
  for devfreq event class drivers. Am I mistaken?
 
 You're right. just class driver description is not proper.
 I'll modify the description of devfreq-event.c as following:
 or If you have other opinion, would you please let me know about it?
 
   devfreq-event: DEVFREQ-Event Framework to provide raw data of Non-CPU 
 Devices.

devfreq-event: a framework to provide raw data and events of devfreq devices

should be enough.


[]
  [snip / reversed maybe.. sorry]
  
  +/**
  + * devfreq_event_is_enabled() - Check whether devfreq-event dev is 
  enabled or
  + * not.
  + * @edev   : the devfreq-event device
  + *
  + * Note that this function check whether devfreq-event dev is enabled or 
  not.
  + * If return true, the devfreq-event dev is enabeld. If return false, the
  + * devfreq-event dev is disabled.
  + */
  +bool devfreq_event_is_enabled(struct devfreq_event_dev *edev)
  +{
  +   bool enabled = false;
  +
  +   if (!edev || !edev-desc)
  +   return enabled;
  +
  +   mutex_lock(edev-lock);
  +
  +   if (edev-enable_count  0)
  +   enabled = true;
  +
  +   if (edev-desc-ops  edev-desc-ops-is_enabled)
  +   enabled |= edev-desc-ops-is_enabled(edev);
  
  What does it mean when enabled_count  0 and ops-is_enabled() is false? 
  or..
  What does it mean when enabled_count = 0 and ops-is_enabled() is true?
  
  If you do enable_count in the subsystem, why would we rely on
  ops-is_enabled()? Are you assuming that a device MAY turn itself off
  without any kernel control (ops-disable()) and it is still a correct
  behabior?
 
 You're right. devfreq_event_is_enabled() has ambiguous operation according to 
 your comment.
 
 I'll only control the enable_count in the subsystem without ops-is_enabled()
 and then remove the is_enabled function in the structre devfreq_event_ops.
 
 Best Regards,
 Chanwoo Choi
 

[Off-Topic]

The name of devfreq-event may look quite intersecting with irq-driven governors,
which are being proposed these days.

Although they may look intersecting, we can have them independently;
this as a sub-class and that as a governor. And we can consider to
provide a common infrastructure for irq-driven mechanisms in devfreq or
devfreq-event when we irq-driven DVFS become more general, which I
expect in 2 ~ 3 years.

So for now, both can go independently.


Cheers!
MyungJoo
N�r��yb�X��ǧv�^�)޺{.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf

Re: [PATCHv4 1/8] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor

[MyungJoo Ham]

Hi Chanwoo,

I love the idea and I now have a little mechanical issues in your code.

 ---
  drivers/devfreq/Kconfig |   2 +
  drivers/devfreq/Makefile|   5 +-
  drivers/devfreq/devfreq-event.c | 449 
 
  drivers/devfreq/event/Makefile  |   1 +
  include/linux/devfreq.h | 160 ++
  5 files changed, 616 insertions(+), 1 deletion(-)
  create mode 100644 drivers/devfreq/devfreq-event.c
  create mode 100644 drivers/devfreq/event/Makefile
 
 diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
 index faf4e70..4d15b62 100644
 --- a/drivers/devfreq/Kconfig
 +++ b/drivers/devfreq/Kconfig
 @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ
 It reads PPMU counters of memory controllers and adjusts the
 operating frequencies and voltages with OPP support.
  
 +comment DEVFREQ Event Drivers
 +
  endif # PM_DEVFREQ
 diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
 index 16138c9..a1ffabe 100644
 --- a/drivers/devfreq/Makefile
 +++ b/drivers/devfreq/Makefile
 @@ -1,4 +1,4 @@
 -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o
 +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o devfreq-event.o
  obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)+= governor_simpleondemand.o
  obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)+= governor_performance.o
  obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)  += governor_powersave.o
 @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)   += governor_userspace.o
  # DEVFREQ Drivers
  obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/
  obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/
 +
 +# DEVFREQ Event Drivers
 +obj-$(CONFIG_PM_DEVFREQ) += event/
 

It looks getting mature fast.
However, I would like to suggest you to

allow not to compile devfreq-event.c and not include its compiled object
  if devfreq.c is required but devfreq-event.c is not required.
  (e.g., add CONFIG_PM_DEVFREQ_EVENT and let it be enabled when needed)
  just a little concern for lightweight devices.
(this change might require a bit more work on the header as well)
  - Or do you think devfreq-event.c will become almost mandatory for
   most devfreq drivers?


[snip]

 diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
 new file mode 100644
 index 000..0e1948e
 --- /dev/null
 +++ b/drivers/devfreq/devfreq-event.c
 @@ -0,0 +1,449 @@
 +/*
 + * devfreq-event: Generic DEVFREQ Event class driver

DEVFREQ is a generic DVFS mechanism (or subsystem).

Plus, I thought devfreq-event is considered to be a framework
for devfreq event class drivers. Am I mistaken?

[snip]

 +struct devfreq_event_dev *devfreq_event_add_edev(struct device *dev,
 +   struct devfreq_event_desc 
 *desc)
 +{
 +   struct devfreq_event_dev *edev;
 +   static atomic_t event_no = ATOMIC_INIT(0);
 +   int ret;
 +
 +   if (!dev || !desc)
 +   return ERR_PTR(-EINVAL);
 +
 +   if (!desc-name || !desc-ops)
 +   return ERR_PTR(-EINVAL);
 +
 +   if (!desc-ops-set_event || !desc-ops-get_event)
 +   return ERR_PTR(-EINVAL);
 +
 +   edev = devm_kzalloc(dev, sizeof(*edev), GFP_KERNEL);
 +   if (!edev)
 +   return ERR_PTR(-ENOMEM);
 +
 +   mutex_lock(devfreq_event_list_lock);

You seem to lock that global lock too long. That lock is only required
while you operate the list. The data to be protected by this mutex is
devfreq_event_list. Until the new entry is added to the list, the new
entry is free from protection. (may be delayed right before list_add)

 +   mutex_init(edev-lock);
 +   edev-desc = desc;
 +   edev-dev.parent = dev;
 +   edev-dev.class = devfreq_event_class;
 +   edev-dev.release = devfreq_event_release_edev;
 +
 +   dev_set_name(edev-dev, event.%d, atomic_inc_return(event_no) - 
 1);
 +   ret = device_register(edev-dev);
 +   if (ret  0) {
 +   put_device(edev-dev);
 +   mutex_unlock(devfreq_event_list_lock);
 +   return ERR_PTR(ret);
 +   }
 +   dev_set_drvdata(edev-dev, edev);
 +
 +   INIT_LIST_HEAD(edev-node);
 +   list_add(edev-node, devfreq_event_list);
 +   mutex_unlock(devfreq_event_list_lock);
 +
 +   return edev;
 +}



[snip / reversed maybe.. sorry]

 +/**
 + * devfreq_event_is_enabled() - Check whether devfreq-event dev is enabled or
 + * not.
 + * @edev   : the devfreq-event device
 + *
 + * Note that this function check whether devfreq-event dev is enabled or not.
 + * If return true, the devfreq-event dev is enabeld. If return false, the
 + * devfreq-event dev is disabled.
 + */
 +bool devfreq_event_is_enabled(struct devfreq_event_dev *edev)
 +{
 +   bool enabled = false;
 +
 +   if (!edev || !edev-desc)
 +   return enabled;
 +
 +   mutex_lock(edev-lock);
 +
 +   if (edev-enable_count  0)
 +   enabled 

Re: [RFC 1/3] devfreq: dt-bindings: Document Exynos3250 devfreq driver

[MyungJoo Ham]

   
  Add documentation for bindings used by Exynos3250 devfreq driver.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  .../bindings/arm/samsung/exynos3250-devfreq.txt| 66 
 ++
  1 file changed, 66 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt
 
 diff --git 
 a/Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt 
 b/Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt
 new file mode 100644
 index ..047955e9e371
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/arm/samsung/exynos3250-devfreq.txt
 @@ -0,0 +1,66 @@
 +Samsung Exynos3250 devfreq driver
 +=
 +
 +The driver support changing frequencies and voltage for:
 + - memory controller and bus,
 + - peripheral buses (left and right).
 +
 +Memory controller and bus
 +=
 +Required properties:
 + - compatible : should be samsung,exynos3250-busfreq-mif
 + - reg : two sets (offset and length of the register) for PPMU registers
 + used by this devfreq driver
 + - clock-names : one clock of name dmc to manage frequency
 + - clocks : phandle and specifier for clock listed in clock-names property
 + - vdd_mif-supply : phandle to MIF voltage regulator
 +
 +Peripheral buses
 +
 +Required properties:
 + - compatible : should be samsung,exynos3250-busfreq-int
 + - reg : two sets (offset and length of the register) for PPMU registers
 + used by this devfreq driver
 + - clock-names : names for PPMU clocks and bus clocks to manage frequencies;
 + All following clock names (and corresponding phandles) must be
 + provided:
 + - ppmu_left, ppmu_right,
 + - aclk_400, aclk_266, aclk_200, aclk_160, aclk_gdl, 
 aclk_gdr, mfc;
 + - clocks : phandles and specifiers for clocks listed in clock-names property
 + - vdd_mif-supply : phandle to INT voltage regulator
 +
 +Example
 +===
 + busfreq_mif: busfreq@106A {
 + compatible = samsung,exynos3250-busfreq-mif;
 + reg = 0x106A 0x2000, 0x106B 0x2000;
 + clocks = cmu_dmc CLK_DIV_DMC;
 + clock-names = dmc;
 + vdd_mif-supply = buck1_reg;
 + status = okay;
 + };

The hardware you are binding hereby is Exynos PPMU.
You may consider to bind PPMU (DMC PPMU or BUS PPMU whichever hardware
you want to use) with DT and then let exynos bus devfreq driver use
the already-bound devices if found, ... in principle.
In other words or point of view, you may implement PPMU driver in
devfreq class device driver so that you let it bind PPMU device with DT.
It may be done similarly with the device below.


Cheers,
MyungJoo.


 +
 + busfreq_int: busfreq@116A {
 + compatible = samsung,exynos3250-busfreq-int;
 + reg = 0x116A 0x2000, 0x112A 0x2000;
 + clocks = cmu CLK_PPMULEFT,
 + cmu CLK_PPMURIGHT,
 + cmu CLK_DIV_ACLK_400_MCUISP,
 + cmu CLK_DIV_ACLK_266,
 + cmu CLK_DIV_ACLK_200,
 + cmu CLK_DIV_ACLK_160,
 + cmu CLK_DIV_GDL,
 + cmu CLK_DIV_GDR,
 + cmu CLK_DIV_MFC;
 + clock-names = ppmuleft,
 + ppmuright,
 + aclk_400,
 + aclk_266,
 + aclk_200,
 + aclk_160,
 + aclk_gdl,
 + aclk_gdr,
 + mfc;
 + vdd_int-supply = buck3_reg;
 + status = okay;
 + };
 -- 
 1.9.1
 

Re: [PATCH] PM / devfreq: remove checks for CONFIG_EXYNOS_ASV

[MyungJoo Ham]

On Fri, May 23, 2014 at 1:52 PM, MyungJoo Ham myungjoo@samsung.com wrote:
 On Thu, May 22, 2014 at 5:37 AM, Paul Bolle pebo...@tiscali.nl wrote:
 Checks for CONFIG_EXYNOS_ASV were added in v3.3. But the related Kconfig
 symbol has never been added to the tree. Remove these checks, as they
 always evaluate to false.

 Signed-off-by: Paul Bolle pebo...@tiscali.nl

 Thanks for pointing this out.

 ASV was supposed to be merged, but it appears it failed or never attempted.

 I will merge with the next batch (this week).


 Cheers,
 MyungJoo.

Uh.. ASV itself affects the power efficiency; thus, I'd like to keep
it alive, but not as the current form.

For 3.16, I'll correct the name following your report. (not going for
3.15RCx anyway)


Then, I'll let it merged into struct busfreq_data for later RCx.


Cheers,
MyungJoo.


 ---
 0) Untested.

 1) I do not really care much for this patch. Two years is not very long
 for dead code to remain in the tree. There is, however, a trivial issue
 that makes this patch stand out from the other patches in my current
 sweep of the tree for Kconfig related problems.

 See, here the use of an unknown Kconfig macro hides an obvious typo: it
 should either be exynos_result_of_asv or exynos4_result_of_asv, but
 not both. Ie, this almost certainly wouldn't have compiled even if the
 Kconfig symbol EXYNOS_ASV would have been part of the tree.

 2) So this makes me wonder whether there are any guidelines for using
 Kconfig macros before the related Kconfig symbols are merged?

  drivers/devfreq/Kconfig  |  3 +--
  drivers/devfreq/exynos/exynos4_bus.c | 13 -
  2 files changed, 1 insertion(+), 15 deletions(-)



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM / devfreq: remove checks for CONFIG_EXYNOS_ASV

[MyungJoo Ham]

On Thu, May 22, 2014 at 5:37 AM, Paul Bolle pebo...@tiscali.nl wrote:
 Checks for CONFIG_EXYNOS_ASV were added in v3.3. But the related Kconfig
 symbol has never been added to the tree. Remove these checks, as they
 always evaluate to false.

 Signed-off-by: Paul Bolle pebo...@tiscali.nl

Thanks for pointing this out.

ASV was supposed to be merged, but it appears it failed or never attempted.

I will merge with the next batch (this week).


Cheers,
MyungJoo.

 ---
 0) Untested.

 1) I do not really care much for this patch. Two years is not very long
 for dead code to remain in the tree. There is, however, a trivial issue
 that makes this patch stand out from the other patches in my current
 sweep of the tree for Kconfig related problems.

 See, here the use of an unknown Kconfig macro hides an obvious typo: it
 should either be exynos_result_of_asv or exynos4_result_of_asv, but
 not both. Ie, this almost certainly wouldn't have compiled even if the
 Kconfig symbol EXYNOS_ASV would have been part of the tree.

 2) So this makes me wonder whether there are any guidelines for using
 Kconfig macros before the related Kconfig symbols are merged?

  drivers/devfreq/Kconfig  |  3 +--
  drivers/devfreq/exynos/exynos4_bus.c | 13 -
  2 files changed, 1 insertion(+), 15 deletions(-)

Re: [PATCH 06/11] PM / devfreq: move definitions for exynos4_bus into drivers/devfreq

[MyungJoo Ham]

On Thu, Dec 19, 2013 at 2:54 AM, Kukjin Kim kgene@samsung.com wrote:
 On 12/18/13 15:11, MyungJoo Ham wrote:

 On Tue, Dec 17, 2013 at 8:52 PM,kg...@kernel.org  wrote:

 From: Kukjin Kimkgene@samsung.com

 We don't need to keep the definitions for exynos4_bus into
 mach-exynos/ so this moves them into drviers/devfreq with
 adding header file.


 Acked-by: MyungJoo Hammyungjoo@samsung.com

 However, how are you going to merge this patch?
 Do you need me to get this handled or are you going to do it yourself
 with Samsung-SoC tree?


 Hi MyungJoo,

 Let me take this into Samsung tree with others if you're OK :-)

Yes, Ok. Please go ahead.


 Thanks,
 Kukjin


 Cheers,
 MyungJoo.


 Cc: MyungJoo Hammyungjoo@samsung.com
 Signed-off-by: Kukjin Kimkgene@samsung.com
 ---
   arch/arm/mach-exynos/include/mach/regs-clock.h |   94
 
   drivers/devfreq/exynos/exynos4_bus.c   |4 +-
   drivers/devfreq/exynos/exynos4_bus.h   |  110
 
   3 files changed, 112 insertions(+), 96 deletions(-)
   create mode 100644 drivers/devfreq/exynos/exynos4_bus.h



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/11] PM / devfreq: move definitions for exynos4_bus into drivers/devfreq

[MyungJoo Ham]

On Tue, Dec 17, 2013 at 8:52 PM,  kg...@kernel.org wrote:
 From: Kukjin Kim kgene@samsung.com

 We don't need to keep the definitions for exynos4_bus into
 mach-exynos/ so this moves them into drviers/devfreq with
 adding header file.

Acked-by: MyungJoo Ham myungjoo@samsung.com

However, how are you going to merge this patch?
Do you need me to get this handled or are you going to do it yourself
with Samsung-SoC tree?

Cheers,
MyungJoo.


 Cc: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos/include/mach/regs-clock.h |   94 
  drivers/devfreq/exynos/exynos4_bus.c   |4 +-
  drivers/devfreq/exynos/exynos4_bus.h   |  110
 
  3 files changed, 112 insertions(+), 96 deletions(-)
  create mode 100644 drivers/devfreq/exynos/exynos4_bus.h


-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/11] PM / devfreq: use inclusion mach/map.h instead of plat/map-s5p.h

[MyungJoo Ham]

On Tue, Dec 17, 2013 at 8:53 PM,  kg...@kernel.org wrote:
 From: Kukjin Kim kgene@samsung.com

 This fixes follwoing warning:
 In file included from drivers/devfreq/exynos/exynos4_bus.h:15:0,
  from drivers/devfreq/exynos/exynos4_bus.c:35:
 arch/arm/mach-exynos/include/mach/map.h:22:0: warning: S3C_UART_OFFSET
 redefined [enabled by default]
 In file included from drivers/devfreq/exynos/exynos4_bus.c:33:0:
 arch/arm/plat-samsung/include/plat/map-s5p.h:57:0: note: this is the
 location of the previous definition

 Cc: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kukjin Kim kgene@samsung.com

Thanks!

Acked-by: MyungJoo Ham myungjoo@samsung.com



Cheers,
MyungJoo.

 ---
  drivers/devfreq/exynos/exynos4_bus.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/devfreq/exynos/exynos4_bus.c
 b/drivers/devfreq/exynos/exynos4_bus.c
 index 16eb406..1ab8cdd 100644
 --- a/drivers/devfreq/exynos/exynos4_bus.c
 +++ b/drivers/devfreq/exynos/exynos4_bus.c
 @@ -30,7 +30,7 @@
  extern unsigned int exynos_result_of_asv;
  #endif

 -#include plat/map-s5p.h
 +#include mach/map.h

  #include exynos4_bus.h

 --
 1.7.10.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/4] PM / devfreq: Consider hibernation in pm notifier

[MyungJoo Ham]

On Tue, Nov 19, 2013 at 10:30 PM, Jonghwan Choi jhbird.c...@gmail.com wrote:
 Frequency lock should be considered in suspend/hibernation.

 Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com

Signed-off-by: MyungJoo Ham myungjoo@samsung.com

Applied in driver-update branch.

Do you want this to be synchronously merged with others (1/4, 2/4) or
is it ok to be done asynchronously?


Cheers,
MyungJoo.

 ---
  drivers/devfreq/exynos/exynos4_bus.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/devfreq/exynos/exynos4_bus.c 
 b/drivers/devfreq/exynos/exynos4_bus.c
 index cede6f7..dd6947e 100644
 --- a/drivers/devfreq/exynos/exynos4_bus.c
 +++ b/drivers/devfreq/exynos/exynos4_bus.c
 @@ -962,6 +962,7 @@ static int exynos4_busfreq_pm_notifier_event(struct 
 notifier_block *this,
 int err = 0;

 switch (event) {
 +   case PM_HIBERNATION_PREPARE:
 case PM_SUSPEND_PREPARE:
 /* Set Fastest and Deactivate DVFS */
 mutex_lock(data-lock);
 @@ -1005,6 +1006,7 @@ unlock:
 if (err)
 return err;
 return NOTIFY_OK;
 +   case PM_POST_HIBERNATION:
 case PM_POST_RESTORE:
 case PM_POST_SUSPEND:
 /* Reactivate */
 --
 1.8.1.2

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] PM / devfreq: Consider hibernation in pm notifier

[MyungJoo Ham]

On Tue, Nov 19, 2013 at 10:30 PM, Jonghwan Choi jhbird.c...@gmail.com wrote:
 Frequency lock should be considered in suspend/hibernation.

 Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com

Signed-off-by: MyungJoo Ham myungjoo@samsung.com




Cheers,
MyungJoo.

 ---
  drivers/devfreq/exynos/exynos5_bus.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/devfreq/exynos/exynos5_bus.c 
 b/drivers/devfreq/exynos/exynos5_bus.c
 index a60da3c..bd672de0 100644
 --- a/drivers/devfreq/exynos/exynos5_bus.c
 +++ b/drivers/devfreq/exynos/exynos5_bus.c
 @@ -268,6 +268,7 @@ static int exynos5_busfreq_int_pm_notifier_event(struct 
 notifier_block *this,
 int err = 0;

 switch (event) {
 +   case PM_HIBERNATION_PREPARE:
 case PM_SUSPEND_PREPARE:
 /* Set Fastest and Deactivate DVFS */
 mutex_lock(data-lock);
 @@ -300,6 +301,7 @@ unlock:
 if (err)
 return NOTIFY_BAD;
 return NOTIFY_OK;
 +   case PM_POST_HIBERNATION:
 case PM_POST_RESTORE:
 case PM_POST_SUSPEND:
 /* Reactivate */
 --
 1.8.1.2

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] PM / devfreq: Consider hibernation in pm notifier

[MyungJoo Ham]

On Wed, Nov 20, 2013 at 7:08 AM, Sebastian Capella
sebastian.cape...@linaro.org wrote:
 Quoting Bartlomiej Zolnierkiewicz (2013-11-19 06:50:05)
 Hi,

 Are you planning to add hibernation support to ARM?

 If so then this should be stated somewhere in the patch description.

 OTOH if you are not going to add hibernation support to ARM I see
 a little sense in adding hibernation support to ARM-only drivers..

 FYI, we at Linaro and a few others have been working on adding
 hibernation support for ARM.  I have not coordinated with Jonghwan
 however.

That is great.

We once tried to upstream hibernation support and forgot it for a while, too.
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036101.html

I have not coordinated with Jonghwan Choi, either.
However, it appears that some others are trying now, too.


Cheers,
MyungJoo


 Apoligies for the earlier toppost.

 Thanks,

 Sebastian Capella
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/4] Add basic support for ASV

[MyungJoo Ham]

On Mon, Nov 11, 2013 at 11:27 PM, Yadwinder Singh Brar
yadi.bra...@gmail.com wrote:
 gentle ping for suggestions/reviews ..


 On Wed, Sep 11, 2013 at 8:14 PM, Yadwinder Singh Brar
 yadi.b...@samsung.com wrote:
 This series is to add basic common infrastructure for ASV.
  Basically ASV is a technique used on samsung SoCs, which provides the
 recommended supply voltage for dvfs of arm, mif etc. For a given operating
 frequency, the voltage is recommended based on SoC's ASV group.
 ASV group gets fussed on SoCs during process of mass production.

ASV is an instance of AVS. Please recondier and try to reuse
what's already there (drivers/power/avs)

Quote from drivers/power/avs/Kconfig:
  At a given operating point the voltage is adapted depending on
  static factors (chip manufacturing process) and dynamic factors
  (temperature depending performance).
It seems that the current ASV is subset of AVS.
Although the current implementation of AVS does not provide significant
infrastructure to its sisters, we may start by sharing the directory.


Added Jean Pihet, who has submitted AVS (TI).

Cheers,
MyungJoo.


 This series includes:
  - basic common infrastructue for ASV. It provides common APIs for user 
 drivers
 like cpufreq  devfreq and and an interface for SoC specific drivers to
 register ASV members(instances)
  - a common platform driver to register ASV members for exynos SoCs
  - an example providing minimal support (only for ARM ASV) for exynos5250 
 chips

 Its just basic skelton which I wanted to get it reviewed or discussed in
 early stage, before going ahead on further development based on it.
  Presently example is based on static ASV table provided in SoC specific 
 file,
 which I expects to go into DT. But exactly how and where needs to be 
 discussed,
 may be in next revisions once we get through the basic skelton.
  Also the location of driver in kernel may also seem odd to someone and
 many more things :).

 Looking for your valuable reviews and suggestions.

 Thanks

 Yadwinder Singh Brar (4):
   power: asv: Add common ASV support for samsung SoCs
   power: asv: Add a common asv driver for exynos SoCs.
   power: asv: Add support for exynos5250
   arm: exynos5: Register static platform device for ASV.

  arch/arm/mach-exynos/mach-exynos5-dt.c   |3 +
  drivers/power/Kconfig|1 +
  drivers/power/Makefile   |1 +
  drivers/power/asv/Kconfig|   24 
  drivers/power/asv/Makefile   |2 +
  drivers/power/asv/exynos-asv.c   |   81 ++
  drivers/power/asv/exynos-asv.h   |   22 
  drivers/power/asv/exynos5250-asv.c   |  141 
  drivers/power/asv/samsung-asv.c  |  175 
 ++
  include/linux/power/samsung-asv-driver.h |   61 +++
  include/linux/power/samsung-asv.h|   37 +++
  11 files changed, 548 insertions(+), 0 deletions(-)
  create mode 100644 drivers/power/asv/Kconfig
  create mode 100644 drivers/power/asv/Makefile
  create mode 100644 drivers/power/asv/exynos-asv.c
  create mode 100644 drivers/power/asv/exynos-asv.h
  create mode 100644 drivers/power/asv/exynos5250-asv.c
  create mode 100644 drivers/power/asv/samsung-asv.c
  create mode 100644 include/linux/power/samsung-asv-driver.h
  create mode 100644 include/linux/power/samsung-asv.h


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] regulator: max8997: skip gpio dvs setup if not used

[MyungJoo Ham]

On Wed, Nov 21, 2012 at 11:23 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
 If gpio based voltage selection for buck 1/2/5 are not used, then the 
 execution
 of gpio dvs setup code during probe can be skipped completly.

Even if GPIO-DVS feature is turned off, you need to setup BUCKxDVS1 anyway.
Otherwise, you may get unspecified behavior from the BUCK1/2/5,
which may incur unstable system.


Cheers,
MyungJoo


-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] regulator: add device tree support for max8997

[MyungJoo Ham]

On Sat, Mar 24, 2012 at 6:49 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
 Add device tree based discovery support for max8997.

 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Rajendra Nayak rna...@ti.com
 Cc: Rob Herring rob.herr...@calxeda.com
 Cc: Grant Likely grant.lik...@secretlab.ca
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org

Acked-by: MyungJoo Ham myungjoo@samsung.com

 ---
  .../devicetree/bindings/regulator/max8997-pmic.txt |  133 ++
  drivers/mfd/max8997.c                              |   73 ++-
  drivers/regulator/max8997.c                        |  143 
 +++-
  include/linux/mfd/max8997-private.h                |    1 +
  include/linux/mfd/max8997.h                        |    1 +
  5 files changed, 347 insertions(+), 4 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/regulator/max8997-pmic.txt

 diff --git a/Documentation/devicetree/bindings/regulator/max8997-pmic.txt 
 b/Documentation/devicetree/bindings/regulator/max8997-pmic.txt
 new file mode 100644
 index 000..90a730b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/regulator/max8997-pmic.txt
 @@ -0,0 +1,133 @@
 +* Maxim MAX8997 Voltage and Current Regulator
 +
 +The Maxim MAX8997 is a multi-function device which includes volatage and
 +current regulators, rtc, charger controller and other sub-blocks. It is
 +interfaced to the host controller using a i2c interface. Each sub-block is
 +addressed by the host system using different i2c slave address. This document
 +describes the bindings for 'pmic' sub-block of max8997.
 +
 +Required properties:
 +- compatible: Should be maxim,max8997-pmic.
 +- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
 +
 +- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt 
 (uV)
 +  units for buck1 when changing voltage using gpio dvs. Refer to [1] below
 +  for additional information.
 +
 +- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt 
 (uV)
 +  units for buck2 when changing voltage using gpio dvs. Refer to [1] below
 +  for additional information.
 +
 +- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt 
 (uV)
 +  units for buck5 when changing voltage using gpio dvs. Refer to [1] below
 +  for additional information.
 +
 +[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
 +    property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage'
 +    property should specify atleast one voltage level (which would be a
 +    safe operating voltage).
 +
 +    If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
 +    property is specified, then all the eigth voltage values for the
 +    'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified.
 +
 +Optional properties:
 +- interrupt-parent: Specifies the phandle of the interrupt controller to 
 which
 +  the interrupts from max8997 are delivered to.
 +- interrupts: Interrupt specifiers for two interrupt sources.
 +  - First interrupt specifier is for 'irq1' interrupt.
 +  - Second interrupt specifier is for 'alert' interrupt.
 +- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs.
 +- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
 +- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs.
 +
 +Additional properties required if either of the optional properties are used:
 +- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for
 +  multiple bucks, changing the voltage value of one of the bucks may affect
 +  that of another buck, which is the side effect of the change (set_voltage).
 +  Use this property to ignore such side effects and change the voltage.
 +
 +- max8997,pmic-buck125-default-dvs-idx: Default voltage setting selected from
 +  the possible 8 options selectable by the dvs gpios. The value of this
 +  property should be between 0 and 7. If not specified or if out of range, 
 the
 +  default value of this property is set to 0.
 +
 +- max8997,pmic-buck125-dvs-gpios: GPIO specifiers for three host gpio's used
 +  for dvs. The format of the gpio specifier depends in the gpio controller.
 +
 +
 +Regulators: The regulators of max8997 that have to be instantiated should be
 +included in a sub-node named 'regulators'. Regulator nodes included in this
 +sub-node should be of the format as below. Note: The 'n' in LDOn and BUCKn
 +represents the LDO or BUCK number as per the datasheet of max8997.
 +
 +    For LDO's:
 +               LDOn {
 +                       standard regulator bindings here
 +               };
 +
 +    For BUCK's:
 +               BUCKn {
 +                       standard regulator bindings here
 +               };
 +
 +The bindings inside the regulator nodes use the standard regulator bindings
 +which are documented elsewhere.
 +
 +Example:
 +
 +       max8997_pmic@66 {
 +               compatible = maxim,max8997-pmic

Re: [PATCH v4 1/2] mfd: add irq domain support for max8997 interrupts

[MyungJoo Ham]

On Sat, Mar 24, 2012 at 6:49 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
 Add irq domain support for max8997 interrupts. The reverse mapping method
 used is linear mapping since the sub-drivers of max8997 such as regulator
 and charger drivers can use the max8997 irq_domain to get the linux irq
 number for max8997 interrupts. All uses of irq_base in platform data and
 max8997 driver private data are removed.

 Cc: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 Acked-by: Grant Likely grant.lik...@secretlab.ca

Acked-by: MyungJoo Ham myungjoo@samsung.com

 ---
  arch/arm/mach-exynos/mach-nuri.c    |    4 --
  arch/arm/mach-exynos/mach-origen.c  |    1 -
  drivers/mfd/max8997-irq.c           |   61 --
  drivers/mfd/max8997.c               |    1 -
  include/linux/mfd/max8997-private.h |    4 ++-
  include/linux/mfd/max8997.h         |    1 -
  6 files changed, 39 insertions(+), 33 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-nuri.c 
 b/arch/arm/mach-exynos/mach-nuri.c
 index 7ac81ce..b21d85d 100644
 --- a/arch/arm/mach-exynos/mach-nuri.c
 +++ b/arch/arm/mach-exynos/mach-nuri.c
 @@ -1077,12 +1077,8 @@ static struct platform_device nuri_max8903_device = {
  static void __init nuri_power_init(void)
  {
        int gpio;
 -       int irq_base = IRQ_GPIO_END + 1;
        int ta_en = 0;

 -       nuri_max8997_pdata.irq_base = irq_base;
 -       irq_base += MAX8997_IRQ_NR;
 -
        gpio = EXYNOS4_GPX0(7);
        gpio_request(gpio, AP_PMIC_IRQ);
        s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(0xf));
 diff --git a/arch/arm/mach-exynos/mach-origen.c 
 b/arch/arm/mach-exynos/mach-origen.c
 index 827cb99..d3b2e9d 100644
 --- a/arch/arm/mach-exynos/mach-origen.c
 +++ b/arch/arm/mach-exynos/mach-origen.c
 @@ -424,7 +424,6 @@ static struct max8997_platform_data __initdata 
 origen_max8997_pdata = {
        .buck1_gpiodvs  = false,
        .buck2_gpiodvs  = false,
        .buck5_gpiodvs  = false,
 -       .irq_base       = IRQ_GPIO_END + 1,

        .ignore_gpiodvs_side_effect = true,
        .buck125_default_idx = 0x0,
 diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
 index 09274cf..00390a1 100644
 --- a/drivers/mfd/max8997-irq.c
 +++ b/drivers/mfd/max8997-irq.c
 @@ -142,7 +142,8 @@ static void max8997_irq_sync_unlock(struct irq_data *data)
  static const inline struct max8997_irq_data *
  irq_to_max8997_irq(struct max8997_dev *max8997, int irq)
  {
 -       return max8997_irqs[irq - max8997-irq_base];
 +       struct irq_data *data = irq_get_irq_data(irq);
 +       return max8997_irqs[data-hwirq];
  }

  static void max8997_irq_mask(struct irq_data *data)
 @@ -182,7 +183,7 @@ static irqreturn_t max8997_irq_thread(int irq, void *data)
        u8 irq_reg[MAX8997_IRQ_GROUP_NR] = {};
        u8 irq_src;
        int ret;
 -       int i;
 +       int i, cur_irq;

        ret = max8997_read_reg(max8997-i2c, MAX8997_REG_INTSRC, irq_src);
        if (ret  0) {
 @@ -269,8 +270,11 @@ static irqreturn_t max8997_irq_thread(int irq, void 
 *data)

        /* Report */
        for (i = 0; i  MAX8997_IRQ_NR; i++) {
 -               if (irq_reg[max8997_irqs[i].group]  max8997_irqs[i].mask)
 -                       handle_nested_irq(max8997-irq_base + i);
 +               if (irq_reg[max8997_irqs[i].group]  max8997_irqs[i].mask) {
 +                       cur_irq = irq_find_mapping(max8997-irq_domain, i);
 +                       if (cur_irq)
 +                               handle_nested_irq(cur_irq);
 +               }
        }

        return IRQ_HANDLED;
 @@ -278,26 +282,40 @@ static irqreturn_t max8997_irq_thread(int irq, void 
 *data)

  int max8997_irq_resume(struct max8997_dev *max8997)
  {
 -       if (max8997-irq  max8997-irq_base)
 -               max8997_irq_thread(max8997-irq_base, max8997);
 +       if (max8997-irq  max8997-irq_domain)
 +               max8997_irq_thread(0, max8997);
 +       return 0;
 +}
 +
 +static int max8997_irq_domain_map(struct irq_domain *d, unsigned int irq,
 +                                       irq_hw_number_t hw)
 +{
 +       struct max8997_dev *max8997 = d-host_data;
 +
 +       irq_set_chip_data(irq, max8997);
 +       irq_set_chip_and_handler(irq, max8997_irq_chip, handle_edge_irq);
 +       irq_set_nested_thread(irq, 1);
 +#ifdef CONFIG_ARM
 +       set_irq_flags(irq, IRQF_VALID);
 +#else
 +       irq_set_noprobe(irq);
 +#endif
        return 0;
  }

 +static struct irq_domain_ops max8997_irq_domain_ops = {
 +       .map = max8997_irq_domain_map,
 +};
 +
  int max8997_irq_init(struct max8997_dev *max8997)
  {
 +       struct irq_domain *domain;
        int i;
 -       int cur_irq;
        int ret;
        u8 val;

        if (!max8997-irq) {
                dev_warn(max8997-dev, No interrupt specified.\n);
 -               max8997-irq_base = 0;
 -               return 0;
 -       }
 -
 -       if (!max8997-irq_base) {
 -               dev_err(max8997-dev, No interrupt base

Re: [PATCH 3/3] PM / devfreq: update the name of EXYNOS clock register

[MyungJoo Ham]

On Tue, Jan 31, 2012 at 1:49 PM, Kukjin Kim kgene@samsung.com wrote:
 According to replacing the name of EXYNOS clock registers,
 this patch updates exynos4_bus.c file where it is used.

 Cc: MyungJoo Ham myungjoo@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Kukjin Kim kgene@samsung.com

Acked-by: MyungJoo Ham myungjoo@samsung.com


Anyway, you are going to keep and apply this patch to your Samsung-SoC
repository, right?

I guess it'd be fine for me to apply this patch in PM/devfreq after
this one's get merged as I'm revising a seperated part of this file.



Thanks.


Cheers!
MyungJo.
 ---
  drivers/devfreq/exynos4_bus.c |  224 
  1 files changed, 112 insertions(+), 112 deletions(-)

 diff --git a/drivers/devfreq/exynos4_bus.c b/drivers/devfreq/exynos4_bus.c
 index 6460577..565aa98 100644
 --- a/drivers/devfreq/exynos4_bus.c
 +++ b/drivers/devfreq/exynos4_bus.c
 @@ -311,51 +311,51 @@ static int exynos4210_set_busclk(struct busfreq_data 
 *data, struct opp *opp)
        /* Change Divider - DMC0 */
        tmp = data-dmc_divtable[index];

 -       __raw_writel(tmp, S5P_CLKDIV_DMC0);
 +       __raw_writel(tmp, EXYNOS4_CLKDIV_DMC0);

        do {
 -               tmp = __raw_readl(S5P_CLKDIV_STAT_DMC0);
 +               tmp = __raw_readl(EXYNOS4_CLKDIV_STAT_DMC0);
        } while (tmp  0x);

        /* Change Divider - TOP */
        tmp = data-top_divtable[index];

 -       __raw_writel(tmp, S5P_CLKDIV_TOP);
 +       __raw_writel(tmp, EXYNOS4_CLKDIV_TOP);

        do {
 -               tmp = __raw_readl(S5P_CLKDIV_STAT_TOP);
 +               tmp = __raw_readl(EXYNOS4_CLKDIV_STAT_TOP);
        } while (tmp  0x1);

        /* Change Divider - LEFTBUS */
 -       tmp = __raw_readl(S5P_CLKDIV_LEFTBUS);
 +       tmp = __raw_readl(EXYNOS4_CLKDIV_LEFTBUS);

 -       tmp = ~(S5P_CLKDIV_BUS_GDLR_MASK | S5P_CLKDIV_BUS_GPLR_MASK);
 +       tmp = ~(EXYNOS4_CLKDIV_BUS_GDLR_MASK | EXYNOS4_CLKDIV_BUS_GPLR_MASK);

        tmp |= ((exynos4210_clkdiv_lr_bus[index][0] 
 -                               S5P_CLKDIV_BUS_GDLR_SHIFT) |
 +                               EXYNOS4_CLKDIV_BUS_GDLR_SHIFT) |
                (exynos4210_clkdiv_lr_bus[index][1] 
 -                               S5P_CLKDIV_BUS_GPLR_SHIFT));
 +                               EXYNOS4_CLKDIV_BUS_GPLR_SHIFT));

 -       __raw_writel(tmp, S5P_CLKDIV_LEFTBUS);
 +       __raw_writel(tmp, EXYNOS4_CLKDIV_LEFTBUS);

        do {
 -               tmp = __raw_readl(S5P_CLKDIV_STAT_LEFTBUS);
 +               tmp = __raw_readl(EXYNOS4_CLKDIV_STAT_LEFTBUS);
        } while (tmp  0x11);

        /* Change Divider - RIGHTBUS */
 -       tmp = __raw_readl(S5P_CLKDIV_RIGHTBUS);
 +       tmp = __raw_readl(EXYNOS4_CLKDIV_RIGHTBUS);

 -       tmp = ~(S5P_CLKDIV_BUS_GDLR_MASK | S5P_CLKDIV_BUS_GPLR_MASK);
 +       tmp = ~(EXYNOS4_CLKDIV_BUS_GDLR_MASK | EXYNOS4_CLKDIV_BUS_GPLR_MASK);

        tmp |= ((exynos4210_clkdiv_lr_bus[index][0] 
 -                               S5P_CLKDIV_BUS_GDLR_SHIFT) |
 +                               EXYNOS4_CLKDIV_BUS_GDLR_SHIFT) |
                (exynos4210_clkdiv_lr_bus[index][1] 
 -                               S5P_CLKDIV_BUS_GPLR_SHIFT));
 +                               EXYNOS4_CLKDIV_BUS_GPLR_SHIFT));

 -       __raw_writel(tmp, S5P_CLKDIV_RIGHTBUS);
 +       __raw_writel(tmp, EXYNOS4_CLKDIV_RIGHTBUS);

        do {
 -               tmp = __raw_readl(S5P_CLKDIV_STAT_RIGHTBUS);
 +               tmp = __raw_readl(EXYNOS4_CLKDIV_STAT_RIGHTBUS);
        } while (tmp  0x11);

        return 0;
 @@ -376,137 +376,137 @@ static int exynos4x12_set_busclk(struct busfreq_data 
 *data, struct opp *opp)
        /* Change Divider - DMC0 */
        tmp = data-dmc_divtable[index];

 -       __raw_writel(tmp, S5P_CLKDIV_DMC0);
 +       __raw_writel(tmp, EXYNOS4_CLKDIV_DMC0);

        do {
 -               tmp = __raw_readl(S5P_CLKDIV_STAT_DMC0);
 +               tmp = __raw_readl(EXYNOS4_CLKDIV_STAT_DMC0);
        } while (tmp  0x);

        /* Change Divider - DMC1 */
 -       tmp = __raw_readl(S5P_CLKDIV_DMC1);
 +       tmp = __raw_readl(EXYNOS4_CLKDIV_DMC1);

 -       tmp = ~(S5P_CLKDIV_DMC1_G2D_ACP_MASK |
 -               S5P_CLKDIV_DMC1_C2C_MASK |
 -               S5P_CLKDIV_DMC1_C2CACLK_MASK);
 +       tmp = ~(EXYNOS4_CLKDIV_DMC1_G2D_ACP_MASK |
 +               EXYNOS4_CLKDIV_DMC1_C2C_MASK |
 +               EXYNOS4_CLKDIV_DMC1_C2CACLK_MASK);

        tmp |= ((exynos4x12_clkdiv_dmc1[index][0] 
 -                               S5P_CLKDIV_DMC1_G2D_ACP_SHIFT) |
 +                               EXYNOS4_CLKDIV_DMC1_G2D_ACP_SHIFT) |
                (exynos4x12_clkdiv_dmc1[index][1] 
 -                               S5P_CLKDIV_DMC1_C2C_SHIFT) |
 +                               EXYNOS4_CLKDIV_DMC1_C2C_SHIFT) |
                (exynos4x12_clkdiv_dmc1[index][2] 
 -                               S5P_CLKDIV_DMC1_C2CACLK_SHIFT

Re: [PATCH] watchdog: fix error in probe() of s3c2410_wdt (reset at booting)

[MyungJoo Ham]

On Tue, Jan 31, 2012 at 4:01 AM, Wim Van Sebroeck w...@iguana.be wrote:
 Hi,

 Yes, if we set wdt_count value properly before request_irq, it's fine.

 Anyway, as registering the device (watchdog_register_device()) may be
 done after request_irq without any problem, moving request_irq right
 before it, not after it should be fine.

 So what that be attached patch then? Could you also test this patch?

This patch looks fine and works. It's tested in Exynos4 machine.

Acked-by: MyungJoo Ham myungjoo@samsung.com


Thanks.

Cheers!
MyungJoo.


 Kind regards,
 Wim.
 ---
 diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
 index 4bc3744..404172f 100644
 --- a/drivers/watchdog/s3c2410_wdt.c
 +++ b/drivers/watchdog/s3c2410_wdt.c
 @@ -312,18 +312,26 @@ static int __devinit s3c2410wdt_probe(struct 
 platform_device *pdev)
        dev = pdev-dev;
        wdt_dev = pdev-dev;

 -       /* get the memory region for the watchdog timer */
 -
        wdt_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
        if (wdt_mem == NULL) {
                dev_err(dev, no memory resource specified\n);
                return -ENOENT;
        }

 +       wdt_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 +       if (wdt_irq == NULL) {
 +               dev_err(dev, no irq resource specified\n);
 +               ret = -ENOENT;
 +               goto err;
 +       }
 +
 +       /* get the memory region for the watchdog timer */
 +
        size = resource_size(wdt_mem);
        if (!request_mem_region(wdt_mem-start, size, pdev-name)) {
                dev_err(dev, failed to get memory region\n);
 -               return -EBUSY;
 +               ret = -EBUSY;
 +               goto err;
        }

        wdt_base = ioremap(wdt_mem-start, size);
 @@ -335,29 +343,17 @@ static int __devinit s3c2410wdt_probe(struct 
 platform_device *pdev)

        DBG(probe: mapped wdt_base=%p\n, wdt_base);

 -       wdt_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 -       if (wdt_irq == NULL) {
 -               dev_err(dev, no irq resource specified\n);
 -               ret = -ENOENT;
 -               goto err_map;
 -       }
 -
 -       ret = request_irq(wdt_irq-start, s3c2410wdt_irq, 0, pdev-name, 
 pdev);
 -       if (ret != 0) {
 -               dev_err(dev, failed to install irq (%d)\n, ret);
 -               goto err_map;
 -       }
 -
        wdt_clock = clk_get(pdev-dev, watchdog);
        if (IS_ERR(wdt_clock)) {
                dev_err(dev, failed to find watchdog clock source\n);
                ret = PTR_ERR(wdt_clock);
 -               goto err_irq;
 +               goto err_map;
        }

        clk_enable(wdt_clock);

 -       if (s3c2410wdt_cpufreq_register()  0) {
 +       ret = s3c2410wdt_cpufreq_register();
 +       if (ret  0) {
                printk(KERN_ERR PFX failed to register cpufreq\n);
                goto err_clk;
        }
 @@ -378,12 +374,18 @@ static int __devinit s3c2410wdt_probe(struct 
 platform_device *pdev)
                                                        cannot start\n);
        }

 +       ret = request_irq(wdt_irq-start, s3c2410wdt_irq, 0, pdev-name, 
 pdev);
 +       if (ret != 0) {
 +               dev_err(dev, failed to install irq (%d)\n, ret);
 +               goto err_cpufreq;
 +       }
 +
        watchdog_set_nowayout(s3c2410_wdd, nowayout);

        ret = watchdog_register_device(s3c2410_wdd);
        if (ret) {
                dev_err(dev, cannot register watchdog (%d)\n, ret);
 -               goto err_cpufreq;
 +               goto err_irq;
        }

        if (tmr_atboot  started == 0) {
 @@ -408,23 +410,26 @@ static int __devinit s3c2410wdt_probe(struct 
 platform_device *pdev)

        return 0;

 + err_irq:
 +       free_irq(wdt_irq-start, pdev);
 +
  err_cpufreq:
        s3c2410wdt_cpufreq_deregister();

  err_clk:
        clk_disable(wdt_clock);
        clk_put(wdt_clock);
 -
 - err_irq:
 -       free_irq(wdt_irq-start, pdev);
 +       wdt_clock = NULL;

  err_map:
        iounmap(wdt_base);

  err_req:
        release_mem_region(wdt_mem-start, size);
 -       wdt_mem = NULL;

 + err:
 +       wdt_irq = NULL;
 +       wdt_mem = NULL;
        return ret;
  }

 @@ -432,18 +437,18 @@ static int __devexit s3c2410wdt_remove(struct 
 platform_device *dev)
  {
        watchdog_unregister_device(s3c2410_wdd);

 +       free_irq(wdt_irq-start, dev);
 +
        s3c2410wdt_cpufreq_deregister();

        clk_disable(wdt_clock);
        clk_put(wdt_clock);
        wdt_clock = NULL;

 -       free_irq(wdt_irq-start, dev);
 -       wdt_irq = NULL;
 -
        iounmap(wdt_base);

        release_mem_region(wdt_mem-start, resource_size(wdt_mem));
 +       wdt_irq = NULL;
        wdt_mem = NULL;
        return 0;
  }



-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info

Re: [PATCH] watchdog: fix error in probe() of s3c2410_wdt (reset at booting)

[MyungJoo Ham]

On Sat, Jan 14, 2012 at 6:45 AM, Wim Van Sebroeck w...@iguana.be wrote:
 Hi,

 On Fri, Jan 13, 2012 at 11:11:17AM +, Russell King - ARM Linux wrote:

 On Fri, Jan 13, 2012 at 02:14:23PM +0900, MyungJoo Ham wrote:
  Probe function of s3c2410 watchdog calls request_irq before initializing
  required value (wdt_count). This incurs resetting watchdog counter value
  and watchdog-reboot during booting up.
 
  This patch addresses such an issue by calling request_irq later.
 
  Error handling in probe function and calling oder in remove function are
  also revised accordingly.

 On the other hand, this patch violates the general principle that you set
 the device up _before_ you publish it to userspace.

 In the case where you add the watchdog device, but then the subsequent
 request_irq() fails, there is a window where the watchdog device could
 be opened and started.  You then fall out through the error paths, and
 the module could be removed.

 Don't do this.  Always setup the device first.  Then publish it.  Never
 the other way around.

 Russell was faster in replying, but I would have given the same NAK:
 the registering of the watchdog means that userspace get access/control over
 the watchdog device. So the request_irq should be done before that.

 In your trouble description you wrote: Probe function of s3c2410 watchdog
 calls request_irq before initializing required value (wdt_count).
 Should we not fix the initialization of the wdt_count value instead of the
 request_irq? i will have a look at the code somewhere this weekend.

 Mvg,
 Wim.


Yes, if we set wdt_count value properly before request_irq, it's fine.

Anyway, as registering the device (watchdog_register_device()) may be
done after request_irq without any problem, moving request_irq right
before it, not after it should be fine.

Thank you.



Cheers!
MyungJoo.

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] watchdog: fix error in probe() of s3c2410_wdt (reset at booting)

[MyungJoo Ham]

Probe function of s3c2410 watchdog calls request_irq before initializing
required value (wdt_count). This incurs resetting watchdog counter value
and watchdog-reboot during booting up.

This patch addresses such an issue by calling request_irq later.

Error handling in probe function and calling oder in remove function are
also revised accordingly.

Reported-by: Chanwoo Park cw00.c...@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/watchdog/s3c2410_wdt.c |   29 +++--
 1 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index a79e384..07bd768 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -342,22 +342,17 @@ static int __devinit s3c2410wdt_probe(struct 
platform_device *pdev)
goto err_map;
}
 
-   ret = request_irq(wdt_irq-start, s3c2410wdt_irq, 0, pdev-name, pdev);
-   if (ret != 0) {
-   dev_err(dev, failed to install irq (%d)\n, ret);
-   goto err_map;
-   }
-
wdt_clock = clk_get(pdev-dev, watchdog);
if (IS_ERR(wdt_clock)) {
dev_err(dev, failed to find watchdog clock source\n);
ret = PTR_ERR(wdt_clock);
-   goto err_irq;
+   goto err_map;
}
 
clk_enable(wdt_clock);
 
-   if (s3c2410wdt_cpufreq_register()  0) {
+   ret = s3c2410wdt_cpufreq_register();
+   if (ret  0) {
printk(KERN_ERR PFX failed to register cpufreq\n);
goto err_clk;
}
@@ -395,6 +390,12 @@ static int __devinit s3c2410wdt_probe(struct 
platform_device *pdev)
s3c2410wdt_stop(s3c2410_wdd);
}
 
+   ret = request_irq(wdt_irq-start, s3c2410wdt_irq, 0, pdev-name, pdev);
+   if (ret != 0) {
+   dev_err(dev, failed to install irq (%d)\n, ret);
+   goto err_reg;
+   }
+
/* print out a statement of readiness */
 
wtcon = readl(wdt_base + S3C2410_WTCON);
@@ -406,6 +407,9 @@ static int __devinit s3c2410wdt_probe(struct 
platform_device *pdev)
 
return 0;
 
+ err_reg:
+   watchdog_unregister_device(s3c2410_wdd);
+
  err_cpufreq:
s3c2410wdt_cpufreq_deregister();
 
@@ -413,9 +417,6 @@ static int __devinit s3c2410wdt_probe(struct 
platform_device *pdev)
clk_disable(wdt_clock);
clk_put(wdt_clock);
 
- err_irq:
-   free_irq(wdt_irq-start, pdev);
-
  err_map:
iounmap(wdt_base);
 
@@ -428,6 +429,9 @@ static int __devinit s3c2410wdt_probe(struct 
platform_device *pdev)
 
 static int __devexit s3c2410wdt_remove(struct platform_device *dev)
 {
+   free_irq(wdt_irq-start, dev);
+   wdt_irq = NULL;
+
watchdog_unregister_device(s3c2410_wdd);
 
s3c2410wdt_cpufreq_deregister();
@@ -436,9 +440,6 @@ static int __devexit s3c2410wdt_remove(struct 
platform_device *dev)
clk_put(wdt_clock);
wdt_clock = NULL;
 
-   free_irq(wdt_irq-start, dev);
-   wdt_irq = NULL;
-
iounmap(wdt_base);
 
release_mem_region(wdt_mem-start, resource_size(wdt_mem));
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pull Requeset: Exynos4 Register Address Update for Devfreq Drivers.

[MyungJoo Ham]

On Sat, Dec 24, 2011 at 10:58 AM, Kukjin Kim kgene@samsung.com wrote:
 As I commented, looks ok to me and will apply patches not pull and since I
 didn't get your answer to ask 'topic branch is required for this', I didn't
 yet.

 As a note, if there is no reason to create based on not -rc, just use -rc.

 Merry Christmas.
 Thanks.



Hello,

Having a topic branch for devfreq is fine and I don't care whether
there is one or not as long as the required registers are supported.

Because the registers added in the patches do not seem to be devfreq
specific, I don't think we should have another branch for this. Thus,
having the patches in your Exynos' branch is also fine.

I'll let future pull-requested branches be rebased on rcX anyway. Thanks.


Cheers! Happy new year!
- MyungJoo

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pull Requeset: Exynos4 Register Address Update for Devfreq Drivers.

[MyungJoo Ham]

Hello,

Please pull the patches for Exynos4 SoCs that support devfreq device
drivers for Exynos4210/4212/4412.

The patches are:
ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
ARM: EXYNOS4: Add clock register addresses for Exynos4x12 bus devfreq driver
ARM Exynos4210-Nuri: support Exynos4210-bus Devfreq driver.

Gitweb: 
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/devfreq-for-samsung
Git Repository: git://git.infradead.org/users/kmpark/linux-samsung
Branch: devfreq-for-samsung

The following changes since commit 390f998509bf049019df0b078c0a6606e0d57fb4:

Merge: e34d6b4 6f6c2aa
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Sun Dec 18 14:28:31 2011 -0800

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6
(2011-12-18 14:28:31 -0800)

are available in the git repository at:

  git://git.infradead.org/users/kmpark/linux-samsung.git devfreq-for-samsung

MyungJoo Ham (3):
  ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
  ARM: EXYNOS4: Add clock register addresses for Exynos4x12 bus
devfreq driver
  ARM Exynos4210-Nuri: support Exynos4210-bus Devfreq driver.

 arch/arm/mach-exynos/cpu.c |7 +++-
 arch/arm/mach-exynos/include/mach/map.h|1 +
 arch/arm/mach-exynos/include/mach/regs-clock.h |   42 
 arch/arm/mach-exynos/mach-nuri.c   |   11 --
 4 files changed, 57 insertions(+), 4 deletions(-)



-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/2] mfd: add irq domain support for max8997 interrupts

[MyungJoo Ham]

On Fri, Dec 9, 2011 at 1:27 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
 Add irq domain support for max8997 interrupts. All uses of irq_base in 
 platform
 data and max8997 driver private data are removed.

 Cc: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org

Looks good to me.

Acked-by: MyungJoo Ham myungjoo@samsung.com

 ---
  arch/arm/mach-exynos/mach-nuri.c    |    4 
  arch/arm/mach-exynos/mach-origen.c  |    1 -
  drivers/mfd/max8997-irq.c           |   33 +++--
  drivers/mfd/max8997.c               |    1 -
  include/linux/mfd/max8997-private.h |    4 +++-
  include/linux/mfd/max8997.h         |    1 -
  6 files changed, 22 insertions(+), 22 deletions(-)

 diff --git a/arch/arm/mach-exynos/mach-nuri.c 
 b/arch/arm/mach-exynos/mach-nuri.c
 index 236bbe1..ae333e5 100644
 --- a/arch/arm/mach-exynos/mach-nuri.c
 +++ b/arch/arm/mach-exynos/mach-nuri.c
 @@ -1077,12 +1077,8 @@ static struct platform_device nuri_max8903_device = {
  static void __init nuri_power_init(void)
  {
        int gpio;
 -       int irq_base = IRQ_GPIO_END + 1;
        int ta_en = 0;

 -       nuri_max8997_pdata.irq_base = irq_base;
 -       irq_base += MAX8997_IRQ_NR;
 -
        gpio = EXYNOS4_GPX0(7);
        gpio_request(gpio, AP_PMIC_IRQ);
        s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(0xf));
 diff --git a/arch/arm/mach-exynos/mach-origen.c 
 b/arch/arm/mach-exynos/mach-origen.c
 index f56d027..588b0a8 100644
 --- a/arch/arm/mach-exynos/mach-origen.c
 +++ b/arch/arm/mach-exynos/mach-origen.c
 @@ -421,7 +421,6 @@ struct max8997_platform_data __initdata 
 origen_max8997_pdata = {
        .buck1_gpiodvs  = false,
        .buck2_gpiodvs  = false,
        .buck5_gpiodvs  = false,
 -       .irq_base       = IRQ_GPIO_END + 1,

        .ignore_gpiodvs_side_effect = true,
        .buck125_default_idx = 0x0,
 diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
 index 09274cf..eb9cad5 100644
 --- a/drivers/mfd/max8997-irq.c
 +++ b/drivers/mfd/max8997-irq.c
 @@ -142,7 +142,8 @@ static void max8997_irq_sync_unlock(struct irq_data *data)
  static const inline struct max8997_irq_data *
  irq_to_max8997_irq(struct max8997_dev *max8997, int irq)
  {
 -       return max8997_irqs[irq - max8997-irq_base];
 +       struct irq_data *data = irq_get_irq_data(irq);
 +       return max8997_irqs[data-hwirq];
  }

  static void max8997_irq_mask(struct irq_data *data)
 @@ -179,10 +180,11 @@ static struct irq_chip max8997_irq_chip = {
  static irqreturn_t max8997_irq_thread(int irq, void *data)
  {
        struct max8997_dev *max8997 = data;
 +       struct irq_domain *domain = max8997-irq_domain;
        u8 irq_reg[MAX8997_IRQ_GROUP_NR] = {};
        u8 irq_src;
        int ret;
 -       int i;
 +       int i, cur_irq;

        ret = max8997_read_reg(max8997-i2c, MAX8997_REG_INTSRC, irq_src);
        if (ret  0) {
 @@ -268,9 +270,9 @@ static irqreturn_t max8997_irq_thread(int irq, void *data)
                irq_reg[i] = ~max8997-irq_masks_cur[i];

        /* Report */
 -       for (i = 0; i  MAX8997_IRQ_NR; i++) {
 +       irq_domain_for_each_irq(domain, i, cur_irq) {
                if (irq_reg[max8997_irqs[i].group]  max8997_irqs[i].mask)
 -                       handle_nested_irq(max8997-irq_base + i);
 +                       handle_nested_irq(cur_irq);
        }

        return IRQ_HANDLED;
 @@ -278,13 +280,14 @@ static irqreturn_t max8997_irq_thread(int irq, void 
 *data)

  int max8997_irq_resume(struct max8997_dev *max8997)
  {
 -       if (max8997-irq  max8997-irq_base)
 -               max8997_irq_thread(max8997-irq_base, max8997);
 +       if (max8997-irq  max8997-irq_domain.irq_base)
 +               max8997_irq_thread(max8997-irq_domain.irq_base, max8997);
        return 0;
  }

  int max8997_irq_init(struct max8997_dev *max8997)
  {
 +       struct irq_domain *domain = max8997-irq_domain;
        int i;
        int cur_irq;
        int ret;
 @@ -292,12 +295,6 @@ int max8997_irq_init(struct max8997_dev *max8997)

        if (!max8997-irq) {
                dev_warn(max8997-dev, No interrupt specified.\n);
 -               max8997-irq_base = 0;
 -               return 0;
 -       }
 -
 -       if (!max8997-irq_base) {
 -               dev_err(max8997-dev, No interrupt base specified.\n);
                return 0;
        }

 @@ -327,9 +324,17 @@ int max8997_irq_init(struct max8997_dev *max8997)
                                        true : false;
        }

 +       domain-irq_base = irq_alloc_descs(-1, 0, MAX8997_IRQ_NR, 0);
 +       if (domain-irq_base  0) {
 +               dev_err(max8997-dev, failed to alloc irq descs\n);
 +               return 0;
 +       }
 +       domain-nr_irq = MAX8997_IRQ_NR;
 +       domain-ops = irq_domain_simple_ops;
 +       irq_domain_add(domain);
 +
        /* Register with genirq */
 -       for (i = 0; i  MAX8997_IRQ_NR; i++) {
 -               cur_irq = i + max8997-irq_base

Re: [PATCH 3/4] ARM Exynos4210-Nuri: remove compiler errors

[MyungJoo Ham]

On Sat, Dec 3, 2011 at 6:26 PM, Kukjin Kim kgene@samsung.com wrote:
 MyungJoo Ham wrote:

 On Fri, Dec 2, 2011 at 5:59 PM, Kukjin Kim kgene@samsung.com wrote:
  MyungJoo Hamm wrote:
 
  What's the 'compiler errors'?
 
  And I don't know why this patch included in this series, maybe this
 should
  be separated from this series?

 The error is:
 arch/arm/mach-exynos/mach-nuri.c: In function 'nuri_power_init':
 arch/arm/mach-exynos/mach-nuri.c:1080:2: error: implicit declaration
 of function 'irq_alloc_descs'

 Well, I couldn't find the 'irq_alloc_descs' at the
 arch/arm/mach-exynos/mach-nuri.c file in my tree and linux-next. Maybe you
 missed submitting some patches?

 And I don't know why inclusion of linux/export.h is needed for
 'irq_alloc_descs'...

 It is due to the recent changes in some of the header files (they
 removed some header inclusion from header fiiles).

 I think, if this is required, this fix should be separated because the build
 error what you said will be happened without this series...

 In this patchset, we are providing a test case (Exynos4210-Nuri) for
 the device driver and we had to resolve the compiler error first.

 If so, yes, firstly that should be fixed...but now don't we need this?

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.


Ah.. as you've mentioned, the compiler error is found to be related
with other unmerged patches (sparse IRQ). Please never mind this
patch. This (patch 3/4) should be dropped from this patchset.

Thank you.



Cheers!
MyungJoo

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/4] ARM Exynos4210-Nuri: remove compiler errors

[MyungJoo Ham]

On Fri, Dec 2, 2011 at 5:59 PM, Kukjin Kim kgene@samsung.com wrote:
 MyungJoo Hamm wrote:

 What's the 'compiler errors'?

 And I don't know why this patch included in this series, maybe this should
 be separated from this series?

The error is:
arch/arm/mach-exynos/mach-nuri.c: In function ‘nuri_power_init’:
arch/arm/mach-exynos/mach-nuri.c:1080:2: error: implicit declaration
of function ‘irq_alloc_descs’
It is due to the recent changes in some of the header files (they
removed some header inclusion from header fiiles).

In this patchset, we are providing a test case (Exynos4210-Nuri) for
the device driver and we had to resolve the compiler error first.

Cheers!
MyungJoo


-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] PM/Devfreq: Exynos4210 Bus/VDD_int

[MyungJoo Ham]

This patchset adds DVFS (Dynamic Voltage and Frequency Scaling)
capability to Exynos4210 memory-bus and vdd_int of the SoC.

The Exynos4210 Bus Devfreq driver uses PPMU counters of memory
controllers (DMC0/DMC1 of Exynos4210), and adjusts OPP based on
the current load.

In other to support Exynos4210-bus devfreq driver (patch 2/4),
we have added patches:
1/4: Enable DMC1, Enable PPMU for DMC0/1.
3/4: Remove compiler errors in Exynos4-Nuri board (Nuri is the
test board for this driver)
4/4: Add Exynos4210-bus devfreq device to Nuri board.

Note that any Exynos4210 board may add this capability by adding
the platform device exynos4210-busfreq and provide a regulator
(VDD_INT) to the added device.

ASV (Adaptive Supply Voltage) capability has been introduced in
the ARM-kernel mailing list. However, it has not been merged, yet.
Thus, the device driver (exynos4210_memorybus.c) has a symbol
CONFIG_EXYNOS4_ASV to block ASV-related code.
With support of ASV, this devfreq driver reduces power consumption
futher; most Exynos4210 SoCs have lower voltage requirement than
the worst case (ASV number 0) scenario.

MyungJoo Ham (4):
  ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
  PM/Devfreq: Add Exynos4210-bus device DVFS driver.
  ARM Exynos4210-Nuri: remove compiler errors
  ARM Exynos4210-Nuri: support Exynos4210-bus Devfreq driver.

 arch/arm/mach-exynos/cpu.c  |7 +-
 arch/arm/mach-exynos/include/mach/map.h |1 +
 arch/arm/mach-exynos/mach-nuri.c|   13 +-
 drivers/devfreq/Kconfig |   12 +
 drivers/devfreq/Makefile|3 +
 drivers/devfreq/exynos4210_memorybus.c  |  636 +++
 6 files changed, 668 insertions(+), 4 deletions(-)
 create mode 100644 drivers/devfreq/exynos4210_memorybus.c

-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.

[MyungJoo Ham]

- Add DMC1
- Enlarge address space for DMC from 4k to 64k so that PPMU registers
  may be accessed.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/cpu.c  |7 ++-
 arch/arm/mach-exynos/include/mach/map.h |1 +
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index 90ec247..8bdcba9 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata = {
}, {
.virtual= (unsigned long)S5P_VA_DMC0,
.pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
-   .length = SZ_4K,
+   .length = SZ_64K,
+   .type   = MT_DEVICE,
+   }, {
+   .virtual= (unsigned long)S5P_VA_DMC1,
+   .pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
+   .length = SZ_64K,
.type   = MT_DEVICE,
}, {
.virtual= (unsigned long)S5P_VA_SROMC,
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index 058541d..870a980 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -57,6 +57,7 @@
 #define EXYNOS4_PA_KEYPAD  0x100A
 
 #define EXYNOS4_PA_DMC00x1040
+#define EXYNOS4_PA_DMC10x1041
 
 #define EXYNOS4_PA_COMBINER0x1044
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] PM/Devfreq: Add Exynos4210-bus device DVFS driver.

[MyungJoo Ham]

Exynos4210-memorybus device driver add DVFS capability for
Exynos4210-Bus (memory). The driver monitors PPMU counters of memory
controllers and adjusts operating frequencies and voltages with OPP.

Dependency (CONFIG_EXYNOS_ASV):
Exynos4210 ASV driver has been posted in the mailing list; however, it
si not yet upstreamed. Although the current revision of Exynos4210 ASV
patch does not contain CONFIG_EXYNOS_ASV, we have added the symbol
to hide the dependent from compilers for now.

However, enabling ASV is essential in most Exynos4210 chips to reduce
the power consumption of Exynos4210 because without ASV, this Devfreq
driver assumes the worst case scenario, which consumes more power.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/devfreq/Kconfig|   12 +
 drivers/devfreq/Makefile   |3 +
 drivers/devfreq/exynos4210_memorybus.c |  636 
 3 files changed, 651 insertions(+), 0 deletions(-)
 create mode 100644 drivers/devfreq/exynos4210_memorybus.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 8f04910..5b1b252 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -65,4 +65,16 @@ config DEVFREQ_GOV_USERSPACE
 
 comment DEVFREQ Drivers
 
+config ARM_EXYNOS4210_MEMORYBUS_DEVFREQ
+   bool ARM Exynos4210 Memory Bus DEVFREQ Driver
+   depends on CPU_EXYNOS4210
+   select ARCH_HAS_OPP
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   help
+ This adds the DEVFREQ driver for Exynos4210 memory bus.
+ This driver is supposed to support busses of other Exynos4 series
+ SoCs as well; however, for now, this driver supports Exynos4210
+ only. It reads PPMU counters of memory controllers and adjusts
+ the operating frequencies and voltages with OPP support.
+
 endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 4564a89..f002de5 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -3,3 +3,6 @@ obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)   += 
governor_simpleondemand.o
 obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)  += governor_performance.o
 obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)+= governor_powersave.o
 obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
+
+# DEVFREQ Drivers
+obj-$(CONFIG_ARM_EXYNOS4210_MEMORYBUS_DEVFREQ) += exynos4210_memorybus.o
diff --git a/drivers/devfreq/exynos4210_memorybus.c 
b/drivers/devfreq/exynos4210_memorybus.c
new file mode 100644
index 000..b950005
--- /dev/null
+++ b/drivers/devfreq/exynos4210_memorybus.c
@@ -0,0 +1,636 @@
+/* drivers/devfreq/exynos4210_memorybus.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ * MyungJoo Ham myungjoo@samsung.com
+ *
+ * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
+ * This version supports EXYNOS4210 only. This changes bus frequencies
+ * and vddint voltages. Exynos4412/4212 should be able to be supported
+ * with minor modifications.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/io.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/suspend.h
+#include linux/opp.h
+#include linux/devfreq.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/module.h
+
+/* Exynos4 ASV has been in the mailing list, but not upstreamed, yet. */
+#ifdef CONFIG_EXYNOS_ASV
+extern unsigned int exynos_result_of_asv;
+#endif
+
+#include mach/regs-clock.h
+
+#include plat/map-s5p.h
+
+/* Assume that the bus is saturated if the utilization is 40% */
+#define BUS_SATURATION_RATIO   40
+
+enum ppmu_counter {
+   PPMU_PMNCNT0 = 0,
+   PPMU_PMCCNT1,
+   PPMU_PMNCNT2,
+   PPMU_PMNCNT3,
+   PPMU_PMNCNT_MAX,
+};
+struct exynos4_ppmu {
+   void __iomem *hw_base;
+   unsigned int ccnt;
+   unsigned int event;
+   unsigned int count[PPMU_PMNCNT_MAX];
+   bool ccnt_overflow;
+   bool count_overflow[PPMU_PMNCNT_MAX];
+};
+
+struct busfreq_data {
+   struct device *dev;
+   struct devfreq *devfreq;
+   bool disabled;
+   struct regulator *vdd_int;
+   struct opp *curr_opp;
+   struct exynos4_ppmu dmc[2];
+   struct notifier_block pm_notifier;
+
+   struct mutex lock;
+};
+
+enum busclk_level_idx {
+   LV_0 = 0,
+   LV_1,
+   LV_2,
+   LV_END
+};
+
+struct bus_opp_table {
+   unsigned int idx;
+   unsigned long mem_clk;
+   unsigned long volt;
+};
+
+struct bus_clkdiv {
+   unsigned int index;
+   unsigned int clkdiv;
+};
+
+static struct bus_opp_table exynos4_busclk_table[] = {
+   {LV_0, 40, 115},
+   {LV_1, 267000, 105},
+   {LV_2, 133000, 1025000

[PATCH 4/4] ARM Exynos4210-Nuri: support Exynos4210-bus Devfreq driver.

[MyungJoo Ham]

Support varying voltages:
- GPIODVS for Buck2 is removed.
- Voltage ragne for Buck2 is widen.

Support Buck2 regulator for Exynos4210-bus devfreq driver:
- Added device name for buck2 regulator
- Added exynos4210-busfreq platform device fro Nuri board.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/mach-nuri.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 4cef1fb..dc4cc1d 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -436,7 +436,7 @@ static struct regulator_consumer_supply __initdata 
max8997_buck1_[] = {
REGULATOR_SUPPLY(vdd_arm, NULL), /* CPUFREQ */
 };
 static struct regulator_consumer_supply __initdata max8997_buck2_[] = {
-   REGULATOR_SUPPLY(vdd_int, NULL), /* CPUFREQ */
+   REGULATOR_SUPPLY(vdd_int, exynos4210-busfreq.0), /* CPUFREQ */
 };
 static struct regulator_consumer_supply __initdata max8997_buck3_[] = {
REGULATOR_SUPPLY(vdd, mali_dev.0), /* G3D of Exynos 4 */
@@ -747,7 +747,7 @@ static struct regulator_init_data __initdata 
max8997_buck2_data = {
.constraints= {
.name   = VINT_1.1V_C210,
.min_uV = 90,
-   .max_uV = 110,
+   .max_uV = 120,
.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
.always_on  = 1,
.state_mem  = {
@@ -962,7 +962,6 @@ static struct max8997_platform_data __initdata 
nuri_max8997_pdata = {
.regulators = nuri_max8997_regulators,
 
.buck125_gpios = { EXYNOS4_GPX0(5), EXYNOS4_GPX0(6), EXYNOS4_GPL0(0) },
-   .buck2_gpiodvs = true,
 
.buck1_voltage[0] = 135, /* 1.35V */
.buck1_voltage[1] = 130, /* 1.3V */
@@ -1244,6 +1243,11 @@ static struct s3c2410_platform_i2c nuri_i2c0_platdata 
__initdata = {
.sda_delay  = 200,
 };
 
+/* DEVFREQ controlling memory/bus */
+static struct platform_device exynos4_bus_devfreq = {
+   .name   = exynos4210-busfreq,
+};
+
 static struct platform_device *nuri_devices[] __initdata = {
/* Samsung Platform Devices */
s3c_device_i2c5, /* PMIC should initialize first */
@@ -1281,6 +1285,7 @@ static struct platform_device *nuri_devices[] __initdata 
= {
nuri_max8903_device,
cam_vdda_fixed_rdev,
cam_8m_12v_fixed_rdev,
+   exynos4_bus_devfreq,
 };
 
 static void __init nuri_map_io(void)
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] ARM Exynos4210-Nuri: remove compiler errors

[MyungJoo Ham]

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/mach-nuri.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 236bbe1..4cef1fb 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -11,6 +11,8 @@
 #include linux/platform_device.h
 #include linux/serial_core.h
 #include linux/input.h
+#include linux/irq.h
+#include linux/export.h
 #include linux/i2c.h
 #include linux/i2c/atmel_mxt_ts.h
 #include linux/i2c-gpio.h
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] Samsung fixes for v3.2

[MyungJoo Ham]

On Thu, Nov 24, 2011 at 6:15 AM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 21 November 2011, Kukjin Kim wrote:
 Please pull samsung-fixes for v3.2 from:

 git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
 samsung-fixes

 This includes fix of inclusion header.
 If any problems, please let me know.


 Pulled, thanks!

 On Monday 21 November 2011, Kyungmin Park wrote:
 Don't you fix the mct compiler error if LOCAL_TIMERS are not defined?

 arch/arm/mach-exynos/mct.c: In function 'exynos4_timer_resources':
 arch/arm/mach-exynos/mct.c:451: error: 'exynos4_mct_tick_isr'
 undeclared (first use in this function)
 arch/arm/mach-exynos/mct.c:451: error: (Each undeclared identifier is
 reported only once
 arch/arm/mach-exynos/mct.c:451: error: for each function it appears in.)
 make[1]: *** [arch/arm/mach-exynos/mct.o] Error 1

 Has a patch been posted for this?

        Arnd

There was a discussion about this and a patch seemed to be ready
although I don't know where:

---[quoting: Re: [PATCH 1/2] ARM: EXYNOS4: convert MCT to percpu
interrupt API from linux-arm-ker...@lists.infradead.org]---

On 10/11/11 23:33, MyungJoo Ham wrote:
 On Thu, Nov 10, 2011 at 6:43 PM, Marc Zyngier marc.zyng...@arm.com wrote:
 On 10/11/11 02:40, MyungJoo Ham wrote:
 On Thu, Nov 3, 2011 at 2:30 AM, Marc Zyngier marc.zyng...@arm.com wrote:
 MCT recently gained per cpu interrupts, and missed the fact that
 ARM has moved to a genirq based implementation.

 This patch converts the driver to the new API.

 Boot tested on Origen.

 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: Marc Zyngier marc.zyng...@arm.com

 There is one concern regarding the CONFIG_LOCAL_TIMER.

 []
  #endif /* CONFIG_LOCAL_TIMERS */

  static void __init exynos4_timer_resources(void)
 @@ -438,6 +442,16 @@ static void __init exynos4_timer_resources(void)
mct_clk = clk_get(NULL, xtal);

clk_rate = clk_get_rate(mct_clk);
 +
 +   if (mct_int_type == MCT_INT_PPI) {
 +   int err;
 +
 +   err = request_percpu_irq(IRQ_MCT_LOCALTIMER,
 +exynos4_mct_tick_isr, MCT,
 +percpu_mct_tick);
 +   WARN(err, MCT: can't request IRQ %d (%d)\n,
 +IRQ_MCT_LOCALTIMER, err);
 +   }
  }


 You've added exynos4_mct_tick_isr, which is defined in
 CONFIG_LOCAL_TIMER section, in the place that is compiled without
 CONFIG_LOCAL_TIMER.
 I guess we are going to stop supporting LOCAL_TIMER in Exynos later
 and this could be a problem with it.

 Yup, this is a problem. It probably means we need to #ifdef that chink
 as well. I'm not sure I get your remark about not supporting LOCAL_TIMER
 though. Are you planning to move away from the LOCAL_TIMER infrastructure?

 Yes, we may need to #ifdef that block.
 And yes, for the Exynos series, I'll need to double check; however, I
 think we are planning to move away from the LOCAL_TIMER for MCT.


I have patches for this already.

- Hide quoted text -

   M.
--
Jazz is not dead. It just smells funny...



-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: exynos4: Add support for AFTR mode cpuidle state

[MyungJoo Ham]

On Thu, Nov 17, 2011 at 8:22 PM, Amit Kachhap amit.kach...@linaro.org wrote:
 On 11 November 2011 13:03, MyungJoo Ham myungjoo@gmail.com wrote:
 On Sat, Nov 5, 2011 at 2:03 AM,  amit.kach...@linaro.org wrote:
 From: Amit Daniel Kachhap amit.kach...@linaro.org

 This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
 cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode.
 This patch ports the code to the latest interfaces to
 save/restore CPU state inclusive of CPU PM notifiers, l2
 resume and cpu_suspend/resume.

 Signed-off-by: Jaecheol Lee jc@samsung.com
 Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
 Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
 ---
 []
 +#define REG_DIRECTGO_ADDR      (samsung_rev() == EXYNOS4210_REV_1_1 ? \
 +                               S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24))
 +#define REG_DIRECTGO_FLAG      (samsung_rev() == EXYNOS4210_REV_1_1 ? \
 +                               S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20))

 []
 +
 +       __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)),
 +                                                REG_DIRECTGO_ADDR);
 +       __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG);
 +
        return 0;

 Hello,


 Why are you using INFORM6 and 7 registers in order to save resume
 address and power-mode flags?

 INFORM0 and 1 have been used in pm.c for the exactly same purpose.
 Please use the same registers in cpuidle.c as well.

 The same part in bootloader (IPL) can handle whether it's
 suspend-to-RAM or AFTR and the both modes are mutually exclusive and
 you only need one value for resume PC.

 Therefore, you can keep the value at the same location, which is the
 method we have been using.
 Hi,

 I tried using INFORM0 and INFORM1 in cpuidle and make it same as pm.c.
 But this doesnt work. Looks like my irom fused code checks for the
 wakeup source and needs INFORM7 and INFORM6 for non sleep wakeups. My
 cpu version is S5PV310AH--0AH1113(Origen board).
 I suggest adding support for both type of wakeups(directly from irom
 and through bootloader).

Hello Amit,

Have you checked the part that checks flags for AFTR mode and
Suspend-to-RAM in IPL?

If your code is checking AFTR flags with INFORM6/7 and PM flags with
INFORM0/1, that is terribly wrong as those two modes are mutually
exclusive and are very similar in terms of IPL codes.

Also, the IPL-bootloader code runs in IRAM where CPU determines
whether to continue to boot or jump to resume address of
suspend-to-RAM or deepidle (AFTR/LPA/...).

If yours works with INFORM0/1 for PM, it should work with INFORM0/1 in
AFTR as well if your (S/W loadable) IPL code is correct and INFORM6/7
is not touched regardless of how your IROM code is written. Please
check your IPL code and try to let AFTR use the same address with PM.
There is no reason to use another INFORM registers for AFTR only.
Please note that pm-related IPL code is not in ROM, but loaded by ROM
part of IPL to RAM from a storage.



To jc.lee,

Could you please check whether your IPL code checks for INFORM0/1 for
both PM and AFTR or INFORM0/1 for PM and INFORM6/7 for AFTR?
If the latter is what your IPL does, then, how does it react when both
INFORM0/1 and INFORM6/7 are set for both PM and AFTR?
The IPL code we have uses INFORM0/1 for both PM and AFTR/LPA.


Cheers!
MyungJoo

 Thanks,
 Amit D

 Besides, the Exynos4210 chipmaker (S.LSI) has told that INFORM6 and 7
 registers are used by in-chip code (iROM or iRAM).


 Cheers!
 MyungJoo



 --
 MyungJoo Ham, Ph.D.
 Mobile Software Platform Lab, DMC Business, Samsung Electronics





-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] ARM: EXYNOS4: Support ASV for Exynos4210

[MyungJoo Ham]

)
 +#define S5P_APLL_CON0L6                        S5P_CLKREG(0x15108)
 +#define S5P_APLL_CON0L5                        S5P_CLKREG(0x1510C)
 +#define S5P_APLL_CON0L4                        S5P_CLKREG(0x15110)
 +#define S5P_APLL_CON0L3                        S5P_CLKREG(0x15114)
 +#define S5P_APLL_CON0L2                        S5P_CLKREG(0x15118)
 +#define S5P_APLL_CON0L1                        S5P_CLKREG(0x1511C)
 +
 +#define S5P_CLKDIV_IEM_L8              S5P_CLKREG(0x15300)
 +#define S5P_CLKDIV_IEM_L7              S5P_CLKREG(0x15304)
 +#define S5P_CLKDIV_IEM_L6              S5P_CLKREG(0x15308)
 +#define S5P_CLKDIV_IEM_L5              S5P_CLKREG(0x1530C)
 +#define S5P_CLKDIV_IEM_L4              S5P_CLKREG(0x15310)
 +#define S5P_CLKDIV_IEM_L3              S5P_CLKREG(0x15314)
 +#define S5P_CLKDIV_IEM_L2              S5P_CLKREG(0x15318)
 +#define S5P_CLKDIV_IEM_L1              S5P_CLKREG(0x1531C)
 +
  #define S5P_APLL_LOCKTIME              (0x1C20)        /* 300us */

  #define S5P_APLLCON0_ENABLE_SHIFT      (31)
 diff --git a/arch/arm/mach-exynos4/include/mach/regs-iem.h 
 b/arch/arm/mach-exynos4/include/mach/regs-iem.h
 new file mode 100644
 index 000..d9bf177
 --- /dev/null
 +++ b/arch/arm/mach-exynos4/include/mach/regs-iem.h
 @@ -0,0 +1,27 @@
 +/* linux/arch/arm/mach-exynos/include/mach/regs-iem.h
 + *
 + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
 + *             http://www.samsung.com/
 + *
 + * EXYNOS4 - IEM(INTELLIGENT ENERGY MANAGEMENT) register discription
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 +*/
 +
 +#ifndef __ASM_ARCH_REGS_IEM_H
 +#define __ASM_ARCH_REGS_IEM_H __FILE__
 +
 +/* Register for IEC  */
 +#define EXYNOS4_IECDPCCR               (0x0)
 +
 +/* Register for APC */
 +#define EXYNOS4_APC_CONTROL            (0x10010)
 +#define EXYNOS4_APC_PREDLYSEL          (0x10024)
 +#define EXYNOS4_APC_DBG_DLYCODE                (0x100E0)
 +
 +#define APC_HPM_EN                     (1  4)
 +#define IEC_EN                         (1  0)
 +
 +#endif /* __ASM_ARCH_REGS_IEM_H */
 --
 1.7.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html




-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: exynos4: Add support for AFTR mode cpuidle state

[MyungJoo Ham]

On Sat, Nov 5, 2011 at 2:03 AM,  amit.kach...@linaro.org wrote:
 From: Amit Daniel Kachhap amit.kach...@linaro.org

 This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
 cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode.
 This patch ports the code to the latest interfaces to
 save/restore CPU state inclusive of CPU PM notifiers, l2
 resume and cpu_suspend/resume.

 Signed-off-by: Jaecheol Lee jc@samsung.com
 Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
 Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
 ---
[]
 +#define REG_DIRECTGO_ADDR  (samsung_rev() == EXYNOS4210_REV_1_1 ? \
 +   S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24))
 +#define REG_DIRECTGO_FLAG  (samsung_rev() == EXYNOS4210_REV_1_1 ? \
 +   S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20))

[]
 +
 +   __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)),
 +REG_DIRECTGO_ADDR);
 +   __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG);
 +
return 0;

Hello,


Why are you using INFORM6 and 7 registers in order to save resume
address and power-mode flags?

INFORM0 and 1 have been used in pm.c for the exactly same purpose.
Please use the same registers in cpuidle.c as well.

The same part in bootloader (IPL) can handle whether it's
suspend-to-RAM or AFTR and the both modes are mutually exclusive and
you only need one value for resume PC.

Therefore, you can keep the value at the same location, which is the
method we have been using.

Besides, the Exynos4210 chipmaker (S.LSI) has told that INFORM6 and 7
registers are used by in-chip code (iROM or iRAM).


Cheers!
MyungJoo



-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] ARM: EXYNOS: Add ASV feature for Exynos4 series

[MyungJoo Ham]

On Thu, Oct 27, 2011 at 10:12 AM, Jongpill Lee boyko@samsung.com wrote:
 This patch adds ASV feature for exynos4 seires.
 Asv(Adoptive support voltage) feature support to get spec of SoC.
 And we can use to adjust voltage for operation SoC usign by ASV result.

 Signed-off-by: Jongpill Lee boyko@samsung.com
 ---
  arch/arm/mach-exynos4/Makefile           |    2 +-
  arch/arm/mach-exynos4/asv.c              |   78 
 ++
  arch/arm/mach-exynos4/include/mach/asv.h |   42 
  3 files changed, 121 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/mach-exynos4/asv.c
  create mode 100644 arch/arm/mach-exynos4/include/mach/asv.h


Hello,


As long as we have mach/asv.h in our hands, we can have the ASV
value stored at the common place declared by this asv.h rather than at
INFORM2 as I've mentioned before at another thread. This location
mach/asv.h seems the perfect location for the purpose. Besides, now,
with Exynos4x12s, I start to hear cases where all the INFORMx
registers are fully used; thus, it seems that it's time to remove
unnecessary usage of the registers.



Cheers!
MyungJoo

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] ARM: EXYNOS: Add ASV feature for Exynos4 series

[MyungJoo Ham]

On Sat, Oct 29, 2011 at 3:48 AM, Sylwester Nawrocki snj...@gmail.com wrote:

 You're putting whole driver under arch/arm/, I'm wondering whether the 
 functionality
 it provides could be handled by some generic framework, like cpufreq or 
 devfreq.
 How this driver is different from cpufreq drivers ?

I think there would be futher usage with ASV if IEM and proper PMICs
are attaches; however, for now, ASV guides proper vddarm and vddint
voltages for each freuquency.

Both drivers in cpufreq(vddarm and arm core freq) and devfreq(vddint
and memory/bus freq.. and GPU or MMC later?) should use the result
value of ASV because they both alter voltages according to the ASV
value.

Thus, if this is going to be located in drivers/, it'd better be in
elsewhere (drivers/misc? drivers/hwmon? ..???) and capable of
providing values to other device drivers, at least to cpufreq and
devfreq drivers.


Cheers!
MyungJoo


 --
 Thanks,
 Sylwester
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html




-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] [CPUFREQ] EXYNOS4210: Add support ASV feature

[MyungJoo Ham]

Hello,

On Wed, Nov 2, 2011 at 9:43 PM, Kukjin Kim kgene@samsung.com wrote:
[]
 +static void __init set_volt_table(void)
 +{
 +       unsigned int tmp, i, asv_group = 0;
 +
 +       tmp = __raw_readl(S5P_INFORM2);

As I've mentioned in the ASV patch thread, do we really need to use an
INFORM register simply to save the id of supported voltage ranges?

Why aren't we using an extern variable here? For example, extern int
asv_group_id; and define it at asv.h or somewhere else.

At reboot, we are going to init ASV driver and will get the ASV value
again; thus, we don't need to use such a preserving register anyway.
At suspend/resume, the value in RAM does not disappear and the IPL
does not care this value; thus, it is meaningless to use INFORM2 for
this value.


 +
 +       switch (tmp   (SUPPORT_FREQ_MASK  SUPPORT_FREQ_SHIFT)) {
 +       case SUPPORT_1200MHZ:
 +               asv_group = (tmp  0xF);
 +               break;
 +       case SUPPORT_1400MHZ:
 +       case SUPPORT_1000MHZ:
 +       default:
 +               /* Not supported and assign typical ASV group */
 +               asv_group = 2;
 +               break;
 +       }
 +
 +       printk(KERN_INFO DVFS: VDD_ARM Voltage table set with %d Group\n,
 asv_group);
 +
 +       for (i = 0 ; i  CPUFREQ_LEVEL_END ; i++)
 +               exynos4_volt_table[i] = asv_voltage[i][asv_group];
 +}
 +
  static int __init exynos4_cpufreq_init(void)
  {
        int i;
        unsigned int tmp;

 +       set_volt_table();
 +
        cpu_clk = clk_get(NULL, armclk);
        if (IS_ERR(cpu_clk))
                return PTR_ERR(cpu_clk);
 --
 1.7.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html




-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] [CPUFREQ] EXYNOS4210: Add DVS lock feature for other driver

[MyungJoo Ham]

 = exynos4_cpufreq_reboot_notifier_call,
 +};
 +
  static struct cpufreq_driver exynos4_driver = {
        .flags          = CPUFREQ_STICKY,
        .verify         = exynos4_verify_speed,
 @@ -391,6 +545,11 @@ static int __init exynos4_cpufreq_init(void)
                goto err_vdd_arm;
        }

 +       register_pm_notifier(exynos4_cpufreq_notifier);
 +       register_reboot_notifier(exynos4_cpufreq_reboot_notifier);
 +
 +       exynos4_cpufreq_init_done = true;
 +
        tmp = __raw_readl(S5P_CLKDIV_CPU);

        for (i = L0; i   CPUFREQ_LEVEL_END; i++) {
 @@ -420,6 +579,9 @@ static int __init exynos4_cpufreq_init(void)

        return 0;
  err_cpufreq:
 +       unregister_reboot_notifier(exynos4_cpufreq_reboot_notifier);
 +       unregister_pm_notifier(exynos4_cpufreq_notifier);
 +
        if (!IS_ERR(arm_regulator))
                regulator_put(arm_regulator);

 --
 1.7.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


Except for the case of PM (suspend/reset), it appears that this
feature is something that is meant to be supported by qos
(linux/pm_qos.h).
Couldn't we simply use the QoS feature to support locking frequency
above some specific levels? With QoS, I guess the implementation
becomes more general and straightforward.
Although we will probably need to use CPU_DMA_LATENCY for this case,
I think it isn't awefully difficult to use DMA-Latency as the metric.

One concern about this is that we are hereby enforcing all the related
device drivers stuck with Exynos4210 only unless others also use
cpufreq_lock_ID and its friends.

Cheers!
MyungJoo.

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/5] [CPUFREQ] EXYNOS4210: Remove code about bus on cpufreq

[MyungJoo Ham]

On Wed, Nov 2, 2011 at 9:42 PM, Kukjin Kim kgene@samsung.com wrote:
 From: Jongpill Lee boyko@samsung.com

 This patch removes code for bus on cpufreq because the code
 for bus frequency changing moves to busfreq driver.
 So code about bus on cpufreq is not necessary.

 Signed-off-by: Jongpill Lee boyko@samsung.com
 Signed-off-by: SangWook Ju sw...@samsung.com
 Signed-off-by: Jaecheol Lee jc@samsung.com
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  drivers/cpufreq/exynos4210-cpufreq.c |  174
 +-
  1 files changed, 1 insertions(+), 173 deletions(-)


Cool!

Now, it's compatible with the Exynos4210 bus devfreq driver.
Are you going to upstream the busfreq in the devfreq framework (at
/drivers/devfreq/) or do you want me to submit the Exynos4210 bus
devfreq driver that is currently on
http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/devfreq
(drivers/devfreq/exynos4210_memorybus.c)

Devfreq is a framework to support DVFS feature for non-CPU devices,
which is at 3.2-next tree.


Cheers!
MyungJoo

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: EXYNOS4: Remove useless codes on NURI board

[MyungJoo Ham]

On Thu, Oct 6, 2011 at 3:31 PM, Kukjin Kim kgene@samsung.com wrote:
 MyungJoo Ham wrote:

 2011/8/19 Kyungmin Park kmp...@infradead.org:
  Maybe charger manager codes are not merged. it's used for charger
 managers.
 
  To Mr. Ham,
  which patches are missing?
 
  Thank you,
  Kyungmin Park

 The patch to register Charger-Manager in Nuri is missing in the file.
 In order to apply that, we will need to modify NTC driver (either
 update hwmon framework or seperate NTC driver into two parts
 (platorm-device + hwmon-device) first so that in-kernel modules can
 read values from NTC.

 If missing some stuff will not be merged in this time, to apply this is
 better to us to remove useless warning message during build and if required,
 we can add it later..

 Is ok to you?

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.


That's fine. I'll resubmit it as soon as charger-manager work is cleared.


Cheers!
MyungJoo

 
  On Fri, Aug 19, 2011 at 10:01 PM, Kukjin Kim kgene@samsung.com
 wrote:
  The 'nuri_cm_devices' is defined but not used.
 
  Cc: Kyungmin Park kyungmin.p...@samsung.com
  Signed-off-by: Kukjin Kim kgene@samsung.com
  ---
   arch/arm/mach-exynos4/mach-nuri.c |    7 ---
   1 files changed, 0 insertions(+), 7 deletions(-)
 
  diff --git a/arch/arm/mach-exynos4/mach-nuri.c
 b/arch/arm/mach-exynos4/mach-
 nuri.c
  index 43be71b..65df994 100644
  --- a/arch/arm/mach-exynos4/mach-nuri.c
  +++ b/arch/arm/mach-exynos4/mach-nuri.c
  @@ -1037,13 +1037,6 @@ static struct platform_device
 nuri_max8903_device
 = {
         },
   };
 
  -static struct device *nuri_cm_devices[] = {
  -       s3c_device_i2c5.dev,
  -       s3c_device_adc.dev,
  -       NULL, /* Reserved for UART */
  -       NULL,
  -};
  -
   static void __init nuri_power_init(void)
   {
         int gpio;
  --
  1.7.1





-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] CPUFREQ: ARM Exynos4210 PM/Suspend Compatibility with Different Bootloaders

[MyungJoo Ham]

Adding Kgene to the recipient list.


Please note that even without the cases using different bootloader, we
might have cases where CPUFREQ calling the target function right
before syscore suspend or right after syscore resume where we might
fail at the target function.

Anyway, I guess CPUFREQ'd be better use suspend callbacks that are
earlier than syscore (preferably somewhere before dpm_suspend or at
dpm_suspend) because CPUFREQ's target callback uses other device
drivers, but this could be just a case of S5PV210 and Exynos4210.


Cheers,
MyungJoo

On Thu, Aug 18, 2011 at 7:45 PM, MyungJoo Ham myungjoo@samsung.com wrote:
 We have various bootloaders for Exynos4210 machines. Some of they
 set the ARM core frequency at boot time even when the boot is a resume
 from suspend-to-RAM. Such changes may create inconsistency in the
 data of CPUFREQ driver and have incurred hang issues with suspend-to-RAM.

 This patch enables to save and restore CPU frequencies with pm-notifier and
 sets the frequency at the initial (boot-time) value so that there wouldn't
 be any inconsistency between bootloader and kernel. This patch does not
 use CPUFREQ's suspend/resume callbacks because they are syscore-ops, which
 do not allow to use mutex that is being used by regulators that are used by
 the target function.

 This also prevents any CPUFREQ transitions during suspend-resume context,
 which could be dangerous at noirq-context along with regulator framework.

 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/cpufreq/exynos4210-cpufreq.c |  106 -
  1 files changed, 102 insertions(+), 4 deletions(-)

 diff --git a/drivers/cpufreq/exynos4210-cpufreq.c 
 b/drivers/cpufreq/exynos4210-cpufreq.c
 index b7c3a84..101898a 100644
 --- a/drivers/cpufreq/exynos4210-cpufreq.c
 +++ b/drivers/cpufreq/exynos4210-cpufreq.c
 @@ -17,6 +17,8 @@
  #include linux/slab.h
  #include linux/regulator/consumer.h
  #include linux/cpufreq.h
 +#include linux/notifier.h
 +#include linux/suspend.h

  #include mach/map.h
  #include mach/regs-clock.h
 @@ -36,6 +38,10 @@ static struct regulator *int_regulator;
  static struct cpufreq_freqs freqs;
  static unsigned int memtype;

 +static unsigned int locking_frequency;
 +static bool frequency_locked;
 +static DEFINE_MUTEX(cpufreq_lock);
 +
  enum exynos4_memory_type {
        DDR2 = 4,
        LPDDR2,
 @@ -405,22 +411,32 @@ static int exynos4_target(struct cpufreq_policy *policy,
  {
        unsigned int index, old_index;
        unsigned int arm_volt, int_volt;
 +       int err = -EINVAL;

        freqs.old = exynos4_getspeed(policy-cpu);

 +       mutex_lock(cpufreq_lock);
 +
 +       if (frequency_locked  target_freq != locking_frequency) {
 +               err = -EAGAIN;
 +               goto out;
 +       }
 +
        if (cpufreq_frequency_table_target(policy, exynos4_freq_table,
                                           freqs.old, relation, old_index))
 -               return -EINVAL;
 +               goto out;

        if (cpufreq_frequency_table_target(policy, exynos4_freq_table,
                                           target_freq, relation, index))
 -               return -EINVAL;
 +               goto out;
 +
 +       err = 0;

        freqs.new = exynos4_freq_table[index].frequency;
        freqs.cpu = policy-cpu;

        if (freqs.new == freqs.old)
 -               return 0;
 +               goto out;

        /* get the voltage value */
        arm_volt = exynos4_volt_table[index].arm_volt;
 @@ -447,10 +463,16 @@ static int exynos4_target(struct cpufreq_policy *policy,

        cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);

 -       return 0;
 +out:
 +       mutex_unlock(cpufreq_lock);
 +       return err;
  }

  #ifdef CONFIG_PM
 +/*
 + * These suspend/resume are used as syscore_ops, it is already too
 + * late to set regulator voltages at this stage.
 + */
  static int exynos4_cpufreq_suspend(struct cpufreq_policy *policy)
  {
        return 0;
 @@ -462,6 +484,78 @@ static int exynos4_cpufreq_resume(struct cpufreq_policy 
 *policy)
  }
  #endif

 +/**
 + * exynos4_cpufreq_pm_notifier - block CPUFREQ's activities in suspend-resume
 + *                     context
 + * @notifier
 + * @pm_event
 + * @v
 + *
 + * While frequency_locked == true, target() ignores every frequency but
 + * locking_frequency. The locking_frequency value is the initial frequency,
 + * which is set by the bootloader. In order to eliminate possible
 + * inconsistency in clock values, we save and restore frequencies during
 + * suspend and resume and block CPUFREQ activities. Note that the standard
 + * suspend/resume cannot be used as they are too deep (syscore_ops) for
 + * regulator actions.
 + */
 +static int exynos4_cpufreq_pm_notifier(struct notifier_block *notifier,
 +                                      unsigned long pm_event, void *v)
 +{
 +       struct cpufreq_policy *policy

Re: [PATCH 3/5] ARM: EXYNOS4: Add support PM for EXYNOS4212

[MyungJoo Ham]

On Wed, Aug 24, 2011 at 10:25 PM, Kukjin Kim kgene@samsung.com wrote:
 From: Jonghwan Choi jhbird.c...@samsung.com

 This patch moves regarding clock stuff of PM into clock
 file to support PM on EXYNOS4210 and EXYNOS4212 with one
 single kernel image. Because some clock registers are
 different on each SoCs.

 Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/mach-exynos4/clock-exynos4210.c        |   38 ++
  arch/arm/mach-exynos4/clock-exynos4212.c        |   34 +
  arch/arm/mach-exynos4/clock.c                   |   89 
 +++
  arch/arm/mach-exynos4/include/mach/regs-clock.h |    4 +
  arch/arm/mach-exynos4/pm.c                      |   79 ++--
  5 files changed, 172 insertions(+), 72 deletions(-)

 diff --git a/arch/arm/mach-exynos4/clock-exynos4210.c 
 b/arch/arm/mach-exynos4/clock-exynos4210.c
 index fe74b91..a4b00b7 100644
 --- a/arch/arm/mach-exynos4/clock-exynos4210.c
 +++ b/arch/arm/mach-exynos4/clock-exynos4210.c
 +static struct sleep_save exynos4210_clock_save[] = {
 +       SAVE_ITEM(S5P_CLKSRC_IMAGE),
 +       SAVE_ITEM(S5P_CLKSRC_LCD1),
 +       SAVE_ITEM(S5P_CLKDIV_IMAGE),
 +       SAVE_ITEM(S5P_CLKDIV_LCD1),
 +       SAVE_ITEM(S5P_CLKSRC_MASK_LCD1),
 +       SAVE_ITEM(S5P_CLKGATE_IP_IMAGE_4210),
 +       SAVE_ITEM(S5P_CLKGATE_IP_LCD1),
 +       SAVE_ITEM(S5P_CLKGATE_IP_PERIR_4210),
 +};
 +
 --- a/arch/arm/mach-exynos4/clock-exynos4212.c
 +++ b/arch/arm/mach-exynos4/clock-exynos4212.c
 +static struct sleep_save exynos4212_clock_save[] = {
 +       SAVE_ITEM(S5P_CLKSRC_IMAGE),
 +       SAVE_ITEM(S5P_CLKDIV_IMAGE),
 +       SAVE_ITEM(S5P_CLKGATE_IP_IMAGE_4212),
 +       SAVE_ITEM(S5P_CLKGATE_IP_PERIR_4212),
 +};
 +
 --- a/arch/arm/mach-exynos4/clock.c
 +++ b/arch/arm/mach-exynos4/clock.c
 +static struct sleep_save exynos4_clock_save[] = {

Hello,

Is there any reason to have the following two
SAVE_ITEM(S5P_CLKSRC_IMAGE),
SAVE_ITEM(S5P_CLKDIV_IMAGE
defined at both clock-exynos4210.c and clock-exynos4212.c, not defined
at clock.c once?


Also, consider using CONFIG_PM_SLEEP rather than CONFIG_PM for
suspend/resume ops.


Cheers!
MyungJoo

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] CPUFREQ: ARM Exynos4210 PM/Suspend Compatibility with Different Bootloaders

[MyungJoo Ham]

We have various bootloaders for Exynos4210 machines. Some of they
set the ARM core frequency at boot time even when the boot is a resume
from suspend-to-RAM. Such changes may create inconsistency in the
data of CPUFREQ driver and have incurred hang issues with suspend-to-RAM.

This patch enables to save and restore CPU frequencies with pm-notifier and
sets the frequency at the initial (boot-time) value so that there wouldn't
be any inconsistency between bootloader and kernel. This patch does not
use CPUFREQ's suspend/resume callbacks because they are syscore-ops, which
do not allow to use mutex that is being used by regulators that are used by
the target function.

This also prevents any CPUFREQ transitions during suspend-resume context,
which could be dangerous at noirq-context along with regulator framework.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/cpufreq/exynos4210-cpufreq.c |  106 -
 1 files changed, 102 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/exynos4210-cpufreq.c 
b/drivers/cpufreq/exynos4210-cpufreq.c
index b7c3a84..101898a 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -17,6 +17,8 @@
 #include linux/slab.h
 #include linux/regulator/consumer.h
 #include linux/cpufreq.h
+#include linux/notifier.h
+#include linux/suspend.h
 
 #include mach/map.h
 #include mach/regs-clock.h
@@ -36,6 +38,10 @@ static struct regulator *int_regulator;
 static struct cpufreq_freqs freqs;
 static unsigned int memtype;
 
+static unsigned int locking_frequency;
+static bool frequency_locked;
+static DEFINE_MUTEX(cpufreq_lock);
+
 enum exynos4_memory_type {
DDR2 = 4,
LPDDR2,
@@ -405,22 +411,32 @@ static int exynos4_target(struct cpufreq_policy *policy,
 {
unsigned int index, old_index;
unsigned int arm_volt, int_volt;
+   int err = -EINVAL;
 
freqs.old = exynos4_getspeed(policy-cpu);
 
+   mutex_lock(cpufreq_lock);
+
+   if (frequency_locked  target_freq != locking_frequency) {
+   err = -EAGAIN;
+   goto out;
+   }
+
if (cpufreq_frequency_table_target(policy, exynos4_freq_table,
   freqs.old, relation, old_index))
-   return -EINVAL;
+   goto out;
 
if (cpufreq_frequency_table_target(policy, exynos4_freq_table,
   target_freq, relation, index))
-   return -EINVAL;
+   goto out;
+
+   err = 0;
 
freqs.new = exynos4_freq_table[index].frequency;
freqs.cpu = policy-cpu;
 
if (freqs.new == freqs.old)
-   return 0;
+   goto out;
 
/* get the voltage value */
arm_volt = exynos4_volt_table[index].arm_volt;
@@ -447,10 +463,16 @@ static int exynos4_target(struct cpufreq_policy *policy,
 
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
 
-   return 0;
+out:
+   mutex_unlock(cpufreq_lock);
+   return err;
 }
 
 #ifdef CONFIG_PM
+/*
+ * These suspend/resume are used as syscore_ops, it is already too
+ * late to set regulator voltages at this stage.
+ */
 static int exynos4_cpufreq_suspend(struct cpufreq_policy *policy)
 {
return 0;
@@ -462,6 +484,78 @@ static int exynos4_cpufreq_resume(struct cpufreq_policy 
*policy)
 }
 #endif
 
+/**
+ * exynos4_cpufreq_pm_notifier - block CPUFREQ's activities in suspend-resume
+ * context
+ * @notifier
+ * @pm_event
+ * @v
+ *
+ * While frequency_locked == true, target() ignores every frequency but
+ * locking_frequency. The locking_frequency value is the initial frequency,
+ * which is set by the bootloader. In order to eliminate possible
+ * inconsistency in clock values, we save and restore frequencies during
+ * suspend and resume and block CPUFREQ activities. Note that the standard
+ * suspend/resume cannot be used as they are too deep (syscore_ops) for
+ * regulator actions.
+ */
+static int exynos4_cpufreq_pm_notifier(struct notifier_block *notifier,
+  unsigned long pm_event, void *v)
+{
+   struct cpufreq_policy *policy = cpufreq_cpu_get(0); /* boot CPU */
+   static unsigned int saved_frequency;
+   unsigned int temp;
+
+   mutex_lock(cpufreq_lock);
+   switch (pm_event) {
+   case PM_SUSPEND_PREPARE:
+   if (frequency_locked)
+   goto out;
+   frequency_locked = true;
+
+   if (locking_frequency) {
+   saved_frequency = exynos4_getspeed(0);
+
+   mutex_unlock(cpufreq_lock);
+   exynos4_target(policy, locking_frequency,
+  CPUFREQ_RELATION_H);
+   mutex_lock(cpufreq_lock);
+   }
+
+   break;
+   case PM_POST_SUSPEND

[PATCH] ARM: EXYNOS4: Add more register addresses of CMU.

[MyungJoo Ham]

These registers are crucial for PM to work properly.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos4/include/mach/regs-clock.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/include/mach/regs-clock.h 
b/arch/arm/mach-exynos4/include/mach/regs-clock.h
index 64bdd24..d493fdb 100644
--- a/arch/arm/mach-exynos4/include/mach/regs-clock.h
+++ b/arch/arm/mach-exynos4/include/mach/regs-clock.h
@@ -36,7 +36,9 @@
 #define S5P_CLKSRC_TOP0S5P_CLKREG(0x0C210)
 #define S5P_CLKSRC_TOP1S5P_CLKREG(0x0C214)
 #define S5P_CLKSRC_CAM S5P_CLKREG(0x0C220)
+#define S5P_CLKSRC_TV  S5P_CLKREG(0x0C224)
 #define S5P_CLKSRC_MFC S5P_CLKREG(0x0C228)
+#define S5P_CLKSRC_G3D S5P_CLKREG(0x0C22C)
 #define S5P_CLKSRC_IMAGE   S5P_CLKREG(0x0C230)
 #define S5P_CLKSRC_LCD0S5P_CLKREG(0x0C234)
 #define S5P_CLKSRC_LCD1S5P_CLKREG(0x0C238)
@@ -64,6 +66,7 @@
 #define S5P_CLKDIV_PERIL3  S5P_CLKREG(0x0C55C)
 #define S5P_CLKDIV_PERIL4  S5P_CLKREG(0x0C560)
 #define S5P_CLKDIV_PERIL5  S5P_CLKREG(0x0C564)
+#define S5P_CLKDIV2_RATIO  S5P_CLKREG(0x0C580)
 
 #define S5P_CLKSRC_MASK_TOPS5P_CLKREG(0x0C310)
 #define S5P_CLKSRC_MASK_CAMS5P_CLKREG(0x0C320)
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/6] ARM: EXYNOS4: Increase NR_IRQS for devices with more IRQs

[MyungJoo Ham]

On Thu, Jul 21, 2011 at 2:04 AM, Kukjin Kim kgene@samsung.com wrote:
 MyungJoo Ham wrote:

 MAX8997/17042, which are used by Exynos4-NURI, use additional IRQ
 numbers after GPIO's IRQs. The patch creates some room for those
 devices.

 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos4/include/mach/irqs.h |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h b/arch/arm/mach-
 exynos4/include/mach/irqs.h
 index 31f6bed..51b5db5 100644
 --- a/arch/arm/mach-exynos4/include/mach/irqs.h
 +++ b/arch/arm/mach-exynos4/include/mach/irqs.h
 @@ -154,6 +154,6 @@
  #define IRQ_GPIO_END         (S5P_GPIOINT_BASE + S5P_GPIOINT_COUNT)

  /* Set the default NR_IRQS */
 -#define NR_IRQS                      (IRQ_GPIO_END)
 +#define NR_IRQS                      (IRQ_GPIO_END + 64)

 I applied but basically, we have to avoid using hard coded value like 64 on
 this. The NR_IRQS depends on CPU not board but this change is needed for
 supporting some specific board and if you need more interrupt numbers, will
 you increase it? It is not good way.

 We need to fix this up next time.

 Thanks.

 Best regards,
 Kgene.

Alright. I'll try to let it assign or change NR_IRQS adaptively either
in run-time, boot-time, or compile-time later as a seperated patch.


Thank you.

- MyungJoo

 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.





-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/6] ARM: EXYNOS4: Increase NR_IRQS for devices with more IRQs

[MyungJoo Ham]

On Thu, Jul 21, 2011 at 2:04 AM, Kukjin Kim kgene@samsung.com wrote:
 MyungJoo Ham wrote:

 MAX8997/17042, which are used by Exynos4-NURI, use additional IRQ
 numbers after GPIO's IRQs. The patch creates some room for those
 devices.

 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos4/include/mach/irqs.h |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h b/arch/arm/mach-
 exynos4/include/mach/irqs.h
 index 31f6bed..51b5db5 100644
 --- a/arch/arm/mach-exynos4/include/mach/irqs.h
 +++ b/arch/arm/mach-exynos4/include/mach/irqs.h
 @@ -154,6 +154,6 @@
  #define IRQ_GPIO_END         (S5P_GPIOINT_BASE + S5P_GPIOINT_COUNT)

  /* Set the default NR_IRQS */
 -#define NR_IRQS                      (IRQ_GPIO_END)
 +#define NR_IRQS                      (IRQ_GPIO_END + 64)

 I applied but basically, we have to avoid using hard coded value like 64 on
 this. The NR_IRQS depends on CPU not board but this change is needed for
 supporting some specific board and if you need more interrupt numbers, will
 you increase it? It is not good way.

 We need to fix this up next time.

 Thanks.

OK.. Then, what about using CONFIG_SPARSE_IRQ and
irq_alloc_descs() at board files?

As long as NR_IRQS is large enough to cover all combiners
(IRQ_GPIO_END is large enough in that sense), it appears to be fine
for us (and tested to be ok).


Thank you.
- MyungJoo


 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.





-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] ARM: EXYNOS4: Add more registers to be saved and restored for PM

[MyungJoo Ham]

On Mon, Jul 18, 2011 at 5:00 PM, Kukjin Kim kgene@samsung.com wrote:
 MyungJoo Ham wrote:

 We need more registers to be saved and restored for PM of Exynos4210.
 Otherwise, with additional drivers running, suspend-to-RAM fails to wake
 up properly. This patch adds registers omitted in the initial PM
 patches.

 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos4/pm.c |   77
 +++-
  1 files changed, 76 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-exynos4/pm.c b/arch/arm/mach-exynos4/pm.c
 index a103c13..24c9265 100644
 --- a/arch/arm/mach-exynos4/pm.c
 +++ b/arch/arm/mach-exynos4/pm.c
 @@ -27,6 +27,8 @@
  #include plat/cpu.h
  #include plat/pm.h
  #include plat/pll.h
 +#include plat/regs-srom.h
 +#include plat/regs-timer.h

  #include mach/regs-irq.h
  #include mach/regs-gpio.h
 @@ -60,14 +62,20 @@ static struct sleep_save exynos4_vpll_save[] = {

  static struct sleep_save exynos4_core_save[] = {
       /* CMU side */
 +     SAVE_ITEM(S5P_CLKSRC_LEFTBUS),

 I think, the reset/default value(0x0, SCLKMPLL) has no problem.

 +     SAVE_ITEM(S5P_CLKOUT_CMU_LEFTBUS),

 This is for debugging? So I think no need this.

 +     SAVE_ITEM(S5P_CLKSRC_RIGHTBUS),

 Same as 'CLKSRC_LEFTBUS'

 +     SAVE_ITEM(S5P_CLKOUT_CMU_RIGHTBUS),

 Same as 'CMU_LEFTBUS'

 +     SAVE_ITEM(S5P_CLKOUT_CMU_TOP),

 For debugging...

 +     SAVE_ITEM(S5P_CLKOUT_CMU_DMC),

 Same as above.

 (snip)

 +     SAVE_ITEM(S5P_APLL_LOCK),
 +     SAVE_ITEM(S5P_MPLL_LOCK),
 +     SAVE_ITEM(S5P_APLL_CON0),
 +     SAVE_ITEM(S5P_APLL_CON1),
 +     SAVE_ITEM(S5P_MPLL_CON0),
 +     SAVE_ITEM(S5P_MPLL_CON1),

 Basically, these value should be set in boot-loader after wake up.

 (snip)

 +     /* PMU */
 +     SAVE_ITEM(S5P_HDMI_PHY_CONTROL),
 +     SAVE_ITEM(S5P_USBOTG_PHY_CONTROL),
 +     SAVE_ITEM(S5P_USBHOST_PHY_CONTROL),
 +     SAVE_ITEM(S5P_DAC_CONTROL),
 +     SAVE_ITEM(S5P_MIPI_CONTROL0),
 +     SAVE_ITEM(S5P_MIPI_CONTROL1),
 +     SAVE_ITEM(S5P_ADC_CONTROL),
 +     SAVE_ITEM(S5P_PCIE_CONTROL),
 +     SAVE_ITEM(S5P_SATA_CONTROL),
 +     SAVE_ITEM(S5P_PMU_DEBUG),
 +     SAVE_ITEM(S5P_ARM_CORE0_CONFIGURATION),
 +     SAVE_ITEM(S5P_ARM_CORE1_CONFIGURATION),
 +     SAVE_ITEM(S5P_ARM_CPU_L2_0_CONFIGURATION),
 +     SAVE_ITEM(S5P_ARM_CPU_L2_1_CONFIGURATION),
 +     SAVE_ITEM(S5P_XUSBXTI_CONFIGURATION),
 +     SAVE_ITEM(S5P_XXTI_CONFIGURATION),
 +     SAVE_ITEM(S5P_PMU_CAM_CONF),
 +     SAVE_ITEM(S5P_PMU_TV_CONF),
 +     SAVE_ITEM(S5P_PMU_MFC_CONF),
 +     SAVE_ITEM(S5P_PMU_G3D_CONF),
 +     SAVE_ITEM(S5P_PMU_LCD0_CONF),
 +     SAVE_ITEM(S5P_PMU_LCD1_CONF),
 +     SAVE_ITEM(S5P_MAUDIO_CONFIGURATION),
 +     SAVE_ITEM(S5P_PMU_GPS_CONF),

 Since PMU part is alive block, so no need.

 +
 +     /* System Controller side */
 +     SAVE_ITEM(S3C_VA_SYS + 0x0210),
 +     SAVE_ITEM(S3C_VA_SYS + 0x0214),
 +     SAVE_ITEM(S3C_VA_SYS + 0x0218),
 +     SAVE_ITEM(S3C_VA_SYS + 0x0220),
 +     SAVE_ITEM(S3C_VA_SYS + 0x0230),

 Hmm..really need this?

 +
       /* GIC side */
       SAVE_ITEM(S5P_VA_GIC_CPU + 0x000),
       SAVE_ITEM(S5P_VA_GIC_CPU + 0x004),
 @@ -232,11 +286,32 @@ static struct sleep_save exynos4_core_save[] = {
       SAVE_ITEM(S5P_VA_GIC_DIST + 0xC20),
       SAVE_ITEM(S5P_VA_GIC_DIST + 0xC24),

 -
       SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x000),
       SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x010),
       SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x020),
       SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x030),
 +     SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x040),
 +     SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x050),
 +     SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x060),
 +     SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x070),
 +     SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x080),
 +     SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x090),

 No need to save/restore external GIC part...

 (snip)

 +     /* PWM Register */
 +     SAVE_ITEM(S3C2410_TCFG0),
 +     SAVE_ITEM(S3C2410_TCFG1),
 +     SAVE_ITEM(S3C64XX_TINT_CSTAT),
 +     SAVE_ITEM(S3C2410_TCON),
 +     SAVE_ITEM(S3C2410_TCNTB(0)),
 +     SAVE_ITEM(S3C2410_TCMPB(0)),
 +     SAVE_ITEM(S3C2410_TCNTO(0)),

 PWM? I'm not sure why this is needed here.

 (snip)

 Others, ok.

 Thanks.

 Best regards,
 Kgene.
 --
 Kukjin Kim kgene@samsung.com, Senior Engineer,
 SW Solution Development Team, Samsung Electronics Co., Ltd.


Hello,


Removing the registers you've mentioned didn't break the PM test as
NURI board also does not use debug clocks.

And, PWM driver appears to backup and restore ctirical register; thus,
we don't need to back them up at pm.c. That's good.

For PLLs, I'll let it rely on bootloader as you've mentioned.

The corrected patch will follow this reply soon.


Thanks.

- MyungJoo

-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc

[PATCH v2 2/2] ARM: EXYNOS4: Add more registers to be saved and restored for PM

[MyungJoo Ham]

We need more registers to be saved and restored for PM of Exynos4210.
Otherwise, with additional drivers running, suspend-to-RAM fails to wake
up properly. This patch adds registers omitted in the initial PM
patches.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
--
Changed from v1
- removed unnecessary registers
- As the patch 1/2 is not changed, it is not re-sent.

---
 arch/arm/mach-exynos4/pm.c |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos4/pm.c b/arch/arm/mach-exynos4/pm.c
index a103c13..5d6f768 100644
--- a/arch/arm/mach-exynos4/pm.c
+++ b/arch/arm/mach-exynos4/pm.c
@@ -27,6 +27,7 @@
 #include plat/cpu.h
 #include plat/pm.h
 #include plat/pll.h
+#include plat/regs-srom.h
 
 #include mach/regs-irq.h
 #include mach/regs-gpio.h
@@ -67,7 +68,9 @@ static struct sleep_save exynos4_core_save[] = {
SAVE_ITEM(S5P_CLKSRC_TOP0),
SAVE_ITEM(S5P_CLKSRC_TOP1),
SAVE_ITEM(S5P_CLKSRC_CAM),
+   SAVE_ITEM(S5P_CLKSRC_TV),
SAVE_ITEM(S5P_CLKSRC_MFC),
+   SAVE_ITEM(S5P_CLKSRC_G3D),
SAVE_ITEM(S5P_CLKSRC_IMAGE),
SAVE_ITEM(S5P_CLKSRC_LCD0),
SAVE_ITEM(S5P_CLKSRC_LCD1),
@@ -94,6 +97,7 @@ static struct sleep_save exynos4_core_save[] = {
SAVE_ITEM(S5P_CLKDIV_PERIL4),
SAVE_ITEM(S5P_CLKDIV_PERIL5),
SAVE_ITEM(S5P_CLKDIV_TOP),
+   SAVE_ITEM(S5P_CLKSRC_MASK_TOP),
SAVE_ITEM(S5P_CLKSRC_MASK_CAM),
SAVE_ITEM(S5P_CLKSRC_MASK_TV),
SAVE_ITEM(S5P_CLKSRC_MASK_LCD0),
@@ -102,6 +106,7 @@ static struct sleep_save exynos4_core_save[] = {
SAVE_ITEM(S5P_CLKSRC_MASK_FSYS),
SAVE_ITEM(S5P_CLKSRC_MASK_PERIL0),
SAVE_ITEM(S5P_CLKSRC_MASK_PERIL1),
+   SAVE_ITEM(S5P_CLKDIV2_RATIO),
SAVE_ITEM(S5P_CLKGATE_SCLKCAM),
SAVE_ITEM(S5P_CLKGATE_IP_CAM),
SAVE_ITEM(S5P_CLKGATE_IP_TV),
@@ -122,8 +127,10 @@ static struct sleep_save exynos4_core_save[] = {
SAVE_ITEM(S5P_CLKGATE_IP_DMC),
SAVE_ITEM(S5P_CLKSRC_CPU),
SAVE_ITEM(S5P_CLKDIV_CPU),
+   SAVE_ITEM(S5P_CLKDIV_CPU + 0x4),
SAVE_ITEM(S5P_CLKGATE_SCLKCPU),
SAVE_ITEM(S5P_CLKGATE_IP_CPU),
+
/* GIC side */
SAVE_ITEM(S5P_VA_GIC_CPU + 0x000),
SAVE_ITEM(S5P_VA_GIC_CPU + 0x004),
@@ -232,11 +239,17 @@ static struct sleep_save exynos4_core_save[] = {
SAVE_ITEM(S5P_VA_GIC_DIST + 0xC20),
SAVE_ITEM(S5P_VA_GIC_DIST + 0xC24),
 
-
SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x000),
SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x010),
SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x020),
SAVE_ITEM(S5P_VA_COMBINER_BASE + 0x030),
+
+   /* SROM side */
+   SAVE_ITEM(S5P_SROM_BW),
+   SAVE_ITEM(S5P_SROM_BC0),
+   SAVE_ITEM(S5P_SROM_BC1),
+   SAVE_ITEM(S5P_SROM_BC2),
+   SAVE_ITEM(S5P_SROM_BC3),
 };
 
 static struct sleep_save exynos4_l2cc_save[] = {
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] rtc: rtc-s3c: allow multiple open / allow no-ioctl-open'ed rtc to have irq.

[MyungJoo Ham]

On Mon, Jul 4, 2011 at 12:40 PM, Changhwan Youn chaos.y...@samsung.com wrote:
 AbwBwAGUAbgAgAC8AIAB
        
 hAGwAbABvAHcAIABuAG8ALQBpAG8AYwB0AGwALQBvAHAAZQBuACcAZQBkACAAcgB0AGMAIAB0AG8AIABoAGEAdgBlACAAaQByAHEALgA=
 x-cr-puzzleid: {71A23705-5400-4E21-9C23-2B1E96E33A68}

 MyungJoo Ham wrote:
 The previous rtc-s3c had two issues related with its IRQ.
 1. Users cannot open rtc multiple times because an open operation calls
 request_irq on the same IRQ. (e.g., two user processes wants to open and
 read RTC time from rtc-s3c at the same time)
 2. If alarm is set and no one has the rtc opened with filesystem
 (either the alarm is set by kernel/boot-loader or user set an alarm
 and closed rtc dev file), the pending bit is not cleared and no further
 interrupt is invoked. When the alarm is used by the system itself such
 as a resume from suspend-to-RAM or other Low-power modes/idle, this is a
 critical issue.

 This patch mitigates these issue by calling request_irq at probe and
 free_irq at remove.

 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[]

 -     return 0;
 +     ret = request_irq(s3c_rtc_alarmno, s3c_rtc_alarmirq,
 +                       IRQF_DISABLED,  s3c2410-rtc alarm, rtc);

 +     if (ret) {
 +             dev_err(pdev-dev, IRQ%d error %d\n, s3c_rtc_alarmno,
 ret);
 +             return ret;
 +     }
 +
 +     ret = request_irq(s3c_rtc_tickno, s3c_rtc_tickirq,
 +                       IRQF_DISABLED,  s3c2410-rtc tick, rtc);
 +
 +     if (ret) {
 +             dev_err(pdev-dev, IRQ%d error %d\n, s3c_rtc_tickno,
 ret);
 +             free_irq(s3c_rtc_alarmno, rtc);
 +     }
 +
 +     return ret;

 You need proper error handlings.

 Regards,
 Changhwan

Ah.. ok, I'll let them go through the error handling code like other errors do.

Thanks.


- MyungJoo


   err_nortc:
       s3c_rtc_enable(pdev, 0);
       clk_disable(rtc_clk);
 --
 1.7.4.1

 --
 You received this message because you are subscribed to rtc-linux.
 Membership options at http://groups.google.com/group/rtc-linux .
 Please read http://groups.google.com/group/rtc-linux/web/checklist
 before submitting a driver.





-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/7] ARM: EXYNOS4: Add external GIC io memory mapping

[MyungJoo Ham]

On Mon, Jun 20, 2011 at 4:34 PM, Changhwan Youn chaos.y...@samsung.com wrote:
 This patch adds external GIC io memory mapping
 to support external GIC on EXYNOS4.

 Signed-off-by: Changhwan Youn chaos.y...@samsung.com
 ---
  arch/arm/mach-exynos4/cpu.c              |   10 ++
  arch/arm/mach-exynos4/include/mach/map.h |    5 +++--
  arch/arm/plat-s5p/include/plat/map-s5p.h |    5 +++--
  3 files changed, 16 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
 index 1196f39..6a1ed74 100644
 --- a/arch/arm/mach-exynos4/cpu.c
 +++ b/arch/arm/mach-exynos4/cpu.c
 @@ -107,6 +107,16 @@ static struct map_desc exynos4_iodesc[] __initdata = {
                .pfn            = __phys_to_pfn(EXYNOS4_PA_AUDSS),
                .length         = SZ_1K,
                .type           = MT_DEVICE,
 +       }, {
 +               .virtual        = (unsigned long)S5P_VA_GIC_CPU,
 +               .pfn            = __phys_to_pfn(EXYNOS4_PA_GIC_CPU),
 +               .length         = SZ_64K,
 +               .type           = MT_DEVICE,
 +       }, {
 +               .virtual        = (unsigned long)S5P_VA_GIC_DIST,
 +               .pfn            = __phys_to_pfn(EXYNOS4_PA_GIC_DIST),
 +               .length         = SZ_64K,
 +               .type           = MT_DEVICE,
        },
  };

 diff --git a/arch/arm/mach-exynos4/include/mach/map.h 
 b/arch/arm/mach-exynos4/include/mach/map.h
 index 57d8074..9d5d797 100644
 --- a/arch/arm/mach-exynos4/include/mach/map.h
 +++ b/arch/arm/mach-exynos4/include/mach/map.h
 @@ -61,10 +61,11 @@

  #define EXYNOS4_PA_COMBINER            0x10448000

Isn't this 0x1044 if we are going to use External GIC?

The user manual says it's 0x1044 for Ext-GIC and 0x10448000 for
Internal-GIC.


-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/6] Update Samsung-SoC ADC to support recent CPUs

[MyungJoo Ham]

Patch 1/6: Add regulator support in ADC driver.
If CONFIG_REGULATOR is enabled, vdd regulator for the ADC driver
(e.g., s5p-adc) should exist for the adc driver.

Patch 2/6: Channel selection method for S5PC110 and Exynos4
Recent Samsung SoCs have different register addresses for
channel selection. Use s5p-adc to support such chips.

Patch 3/6: Bugfix for suspend/resume of ADC driver.

Patch 4/6: Support ADC at Exynos4
Define register addresses and device name for Exynos4

Patch 5/6: Support ADC at S5PC110/S5PV210
Correct ADC device name for S5PC110/S5PV210

Patch 6/6: Header file correction (plat/devs.h)
The long-overdue bugfix for compiler errors. ADC for Exynos4 fails to
be compiled without this patch.


MyungJoo Ham (6):
  Samsung SoC ADC: use regulator (VDD for ADC).
  Samsung SoC ADC: Channel selection for S5PV210, S5PC110, and Exynos4
  Samsung SoC ADC: Revise PM for 12-bit ADC operations
  ARM: EXYNOS4: Support ADC
  ARM: S5PC110/S5PV210: Support ADC
  Samsung SoC: header file revised to prevent declaring duplicated.

 arch/arm/mach-exynos4/Kconfig |1 +
 arch/arm/mach-exynos4/cpu.c   |4 +
 arch/arm/mach-exynos4/include/mach/irqs.h |3 +
 arch/arm/mach-exynos4/include/mach/map.h  |5 ++
 arch/arm/mach-s5pv210/cpu.c   |2 +-
 arch/arm/plat-samsung/adc.c   |   84 +++--
 arch/arm/plat-samsung/include/plat/devs.h |5 ++
 arch/arm/plat-samsung/include/plat/regs-adc.h |1 +
 8 files changed, 84 insertions(+), 21 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/6] Samsung SoC ADC: Channel selection for S5PV210, S5PC110, and Exynos4

[MyungJoo Ham]

In S5PV210/S5PC110/Exynos4, ADCMUX channel selection uses ADCMUX
register, not ADCCON register. This patch corrects the behavior of
Samsung-ADC for such cpus.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
--
updates from v2
- Renamed internal device names.
---
 arch/arm/plat-samsung/adc.c   |   29 
 arch/arm/plat-samsung/include/plat/regs-adc.h |1 +
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index 2224128..45cc7e6 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -40,8 +40,9 @@
  */
 
 enum s3c_cpu_type {
-   TYPE_S3C24XX,
-   TYPE_S3C64XX
+   TYPE_ADCV1, /* S3C24XX */
+   TYPE_ADCV2, /* S3C64XX, S5P64X0, S5PC100 */
+   TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
 };
 
 struct s3c_adc_client {
@@ -93,6 +94,7 @@ static inline void s3c_adc_select(struct adc_device *adc,
  struct s3c_adc_client *client)
 {
unsigned con = readl(adc-regs + S3C2410_ADCCON);
+   enum s3c_cpu_type cpu = platform_get_device_id(adc-pdev)-driver_data;
 
client-select_cb(client, 1);
 
@@ -100,8 +102,12 @@ static inline void s3c_adc_select(struct adc_device *adc,
con = ~S3C2410_ADCCON_STDBM;
con = ~S3C2410_ADCCON_STARTMASK;
 
-   if (!client-is_ts)
-   con |= S3C2410_ADCCON_SELMUX(client-channel);
+   if (!client-is_ts) {
+   if (cpu == TYPE_ADCV3)
+   writel(client-channel  0xf, adc-regs + S5P_ADCMUX);
+   else
+   con |= S3C2410_ADCCON_SELMUX(client-channel);
+   }
 
writel(con, adc-regs + S3C2410_ADCCON);
 }
@@ -287,8 +293,8 @@ static irqreturn_t s3c_adc_irq(int irq, void *pw)
 
client-nr_samples--;
 
-   if (cpu == TYPE_S3C64XX) {
-   /* S3C64XX ADC resolution is 12-bit */
+   if (cpu != TYPE_ADCV1) {
+   /* S3C64XX/S5P ADC resolution is 12-bit */
data0 = 0xfff;
data1 = 0xfff;
} else {
@@ -314,7 +320,7 @@ static irqreturn_t s3c_adc_irq(int irq, void *pw)
}
 
 exit:
-   if (cpu == TYPE_S3C64XX) {
+   if (cpu != TYPE_ADCV1) {
/* Clear ADC interrupt */
writel(0, adc-regs + S3C64XX_ADCCLRINT);
}
@@ -388,7 +394,7 @@ static int s3c_adc_probe(struct platform_device *pdev)
clk_enable(adc-clk);
 
tmp = adc-prescale | S3C2410_ADCCON_PRSCEN;
-   if (platform_get_device_id(pdev)-driver_data == TYPE_S3C64XX) {
+   if (platform_get_device_id(pdev)-driver_data != TYPE_ADCV1) {
/* Enable 12-bit ADC resolution */
tmp |= S3C64XX_ADCCON_RESSEL;
}
@@ -476,10 +482,13 @@ static int s3c_adc_resume(struct platform_device *pdev)
 static struct platform_device_id s3c_adc_driver_ids[] = {
{
.name   = s3c24xx-adc,
-   .driver_data= TYPE_S3C24XX,
+   .driver_data= TYPE_ADCV1,
}, {
.name   = s3c64xx-adc,
-   .driver_data= TYPE_S3C64XX,
+   .driver_data= TYPE_ADCV2,
+   }, {
+   .name   = samsung-adc-v3,
+   .driver_data= TYPE_ADCV3,
},
{ }
 };
diff --git a/arch/arm/plat-samsung/include/plat/regs-adc.h 
b/arch/arm/plat-samsung/include/plat/regs-adc.h
index 7554c4f..035e8c3 100644
--- a/arch/arm/plat-samsung/include/plat/regs-adc.h
+++ b/arch/arm/plat-samsung/include/plat/regs-adc.h
@@ -21,6 +21,7 @@
 #define S3C2410_ADCDAT1   S3C2410_ADCREG(0x10)
 #define S3C64XX_ADCUPDNS3C2410_ADCREG(0x14)
 #define S3C64XX_ADCCLRINT  S3C2410_ADCREG(0x18)
+#define S5P_ADCMUX S3C2410_ADCREG(0x1C)
 #define S3C64XX_ADCCLRINTPNDNUPS3C2410_ADCREG(0x20)
 
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/6] Samsung SoC ADC: use regulator (VDD for ADC).

[MyungJoo Ham]

This patch allows the Samsung ADC driver to enable VDD regulator at
probe and resume and to disable at exit and suspend.
In a platform where ADC's VDD regulator is not always-on, this control
is required although this patch does not provide fine-grained power
control (turning on the regulator only when being accessed).

However, if VDD regulator (vdd for the adc device) is not provided,
the regulator control will not be activated because there are platforms
that do not provide regulator for ADC device.

arch_initcall has been modified to module_init in order to allow
regulators to be available at probe.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

--
changed from v2 with valuable comments from Mark Brown.
- Bugfix on error handling
- Faster escape when error at resume function
changes from v1
- Removed macro defining the name of regulator.
- Handle error from regulator_enable.
- Do not allow not to have the regulator if CONFIG_REGULATOR.
- Seperate a patch dealing with arch_initcall-module_init
---
 arch/arm/plat-samsung/adc.c |   31 +++
 1 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index e8f2be2..2224128 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -21,6 +21,7 @@
 #include linux/clk.h
 #include linux/interrupt.h
 #include linux/io.h
+#include linux/regulator/consumer.h
 
 #include plat/regs-adc.h
 #include plat/adc.h
@@ -71,6 +72,7 @@ struct adc_device {
unsigned int prescale;
 
int  irq;
+   struct regulator*vdd;
 };
 
 static struct adc_device *adc_dev;
@@ -338,17 +340,24 @@ static int s3c_adc_probe(struct platform_device *pdev)
adc-pdev = pdev;
adc-prescale = S3C2410_ADCCON_PRSCVL(49);
 
+   adc-vdd = regulator_get(dev, vdd);
+   if (IS_ERR(adc-vdd)) {
+   dev_err(dev, operating without regulator \vdd\ .\n);
+   ret = PTR_ERR(adc-vdd);
+   goto err_alloc;
+   }
+
adc-irq = platform_get_irq(pdev, 1);
if (adc-irq = 0) {
dev_err(dev, failed to get adc irq\n);
ret = -ENOENT;
-   goto err_alloc;
+   goto err_reg;
}
 
ret = request_irq(adc-irq, s3c_adc_irq, 0, dev_name(dev), adc);
if (ret  0) {
dev_err(dev, failed to attach adc irq\n);
-   goto err_alloc;
+   goto err_reg;
}
 
adc-clk = clk_get(dev, adc);
@@ -372,6 +381,10 @@ static int s3c_adc_probe(struct platform_device *pdev)
goto err_clk;
}
 
+   ret = regulator_enable(adc-vdd);
+   if (ret)
+   goto err_ioremap;
+
clk_enable(adc-clk);
 
tmp = adc-prescale | S3C2410_ADCCON_PRSCEN;
@@ -388,12 +401,15 @@ static int s3c_adc_probe(struct platform_device *pdev)
 
return 0;
 
+ err_ioremap:
+   iounmap(adc-regs);
  err_clk:
clk_put(adc-clk);
 
  err_irq:
free_irq(adc-irq, adc);
-
+ err_reg:
+   regulator_put(adc-vdd);
  err_alloc:
kfree(adc);
return ret;
@@ -406,6 +422,8 @@ static int __devexit s3c_adc_remove(struct platform_device 
*pdev)
iounmap(adc-regs);
free_irq(adc-irq, adc);
clk_disable(adc-clk);
+   regulator_disable(adc-vdd);
+   regulator_put(adc-vdd);
clk_put(adc-clk);
kfree(adc);
 
@@ -428,6 +446,7 @@ static int s3c_adc_suspend(struct platform_device *pdev, 
pm_message_t state)
disable_irq(adc-irq);
spin_unlock_irqrestore(adc-lock, flags);
clk_disable(adc-clk);
+   regulator_disable(adc-vdd);
 
return 0;
 }
@@ -435,7 +454,11 @@ static int s3c_adc_suspend(struct platform_device *pdev, 
pm_message_t state)
 static int s3c_adc_resume(struct platform_device *pdev)
 {
struct adc_device *adc = platform_get_drvdata(pdev);
+   int ret;
 
+   ret = regulator_enable(adc-vdd);
+   if (ret)
+   return ret;
clk_enable(adc-clk);
enable_irq(adc-irq);
 
@@ -485,4 +508,4 @@ static int __init adc_init(void)
return ret;
 }
 
-arch_initcall(adc_init);
+module_init(adc_init);
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/6] ARM: EXYNOS4: Support ADC

[MyungJoo Ham]

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
--
Updates from v2
- Based on EXT_GIC patches from Changhwan Youn (ARM: EXYNOS4: Adds
  External GIC)
---
 arch/arm/mach-exynos4/Kconfig |1 +
 arch/arm/mach-exynos4/cpu.c   |4 
 arch/arm/mach-exynos4/include/mach/irqs.h |3 +++
 arch/arm/mach-exynos4/include/mach/map.h  |5 +
 4 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 0aca083..80f4fbe 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -184,6 +184,7 @@ config MACH_NURI
select EXYNOS4_SETUP_SDHCI
select EXYNOS4_SETUP_USB_PHY
select SAMSUNG_DEV_PWM
+   select SAMSUNG_DEV_ADC
help
  Machine support for Samsung Mobile NURI Board.
 
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 5423ed8..7ffa81d 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -21,7 +21,9 @@
 
 #include plat/cpu.h
 #include plat/clock.h
+#include plat/devs.h
 #include plat/exynos4.h
+#include plat/adc-core.h
 #include plat/sdhci.h
 #include plat/devs.h
 #include plat/fimc-core.h
@@ -141,6 +143,8 @@ void __init exynos4_map_io(void)
exynos4_default_sdhci2();
exynos4_default_sdhci3();
 
+   s3c_adc_setname(samsung-adc-v3);
+
s3c_fimc_setname(0, exynos4-fimc);
s3c_fimc_setname(1, exynos4-fimc);
s3c_fimc_setname(2, exynos4-fimc);
diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h 
b/arch/arm/mach-exynos4/include/mach/irqs.h
index 250427f..31f6bed 100644
--- a/arch/arm/mach-exynos4/include/mach/irqs.h
+++ b/arch/arm/mach-exynos4/include/mach/irqs.h
@@ -139,6 +139,9 @@
 
 #define MAX_COMBINER_NR16
 
+#define IRQ_ADCIRQ_ADC0
+#define IRQ_TC IRQ_PEN0
+
 #define S5P_IRQ_EINT_BASE  COMBINER_IRQ(MAX_COMBINER_NR, 0)
 
 #define S5P_EINT_BASE1 (S5P_IRQ_EINT_BASE + 0)
diff --git a/arch/arm/mach-exynos4/include/mach/map.h 
b/arch/arm/mach-exynos4/include/mach/map.h
index e4b5c79..e03e820 100644
--- a/arch/arm/mach-exynos4/include/mach/map.h
+++ b/arch/arm/mach-exynos4/include/mach/map.h
@@ -110,6 +110,9 @@
 
 #define EXYNOS4_PA_IIC(x)  (0x1386 + ((x) * 0x1))
 
+#define EXYNOS4_PA_ADC 0x1391
+#define EXYNOS4_PA_ADC10x13911000
+
 #define EXYNOS4_PA_AC970x139A
 
 #define EXYNOS4_PA_SPDIF   0x139B
@@ -132,6 +135,8 @@
 #define S3C_PA_IIC5EXYNOS4_PA_IIC(5)
 #define S3C_PA_IIC6EXYNOS4_PA_IIC(6)
 #define S3C_PA_IIC7EXYNOS4_PA_IIC(7)
+#define SAMSUNG_PA_ADC EXYNOS4_PA_ADC
+#define SAMSUNG_PA_ADC1EXYNOS4_PA_ADC1
 #define S3C_PA_RTC EXYNOS4_PA_RTC
 #define S3C_PA_WDT EXYNOS4_PA_WATCHDOG
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/6] Samsung SoC ADC: Revise PM for 12-bit ADC operations

[MyungJoo Ham]

- Fixed: 12bit precision is lost at suspend/resume
- Updated: use pm_dev_ops

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/plat-samsung/adc.c |   24 ++--
 1 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index 45cc7e6..ee8deef 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -437,8 +437,10 @@ static int __devexit s3c_adc_remove(struct platform_device 
*pdev)
 }
 
 #ifdef CONFIG_PM
-static int s3c_adc_suspend(struct platform_device *pdev, pm_message_t state)
+static int s3c_adc_suspend(struct device *dev)
 {
+   struct platform_device *pdev = container_of(dev,
+   struct platform_device, dev);
struct adc_device *adc = platform_get_drvdata(pdev);
unsigned long flags;
u32 con;
@@ -457,10 +459,13 @@ static int s3c_adc_suspend(struct platform_device *pdev, 
pm_message_t state)
return 0;
 }
 
-static int s3c_adc_resume(struct platform_device *pdev)
+static int s3c_adc_resume(struct device *dev)
 {
+   struct platform_device *pdev = container_of(dev,
+   struct platform_device, dev);
struct adc_device *adc = platform_get_drvdata(pdev);
int ret;
+   unsigned long tmp;
 
ret = regulator_enable(adc-vdd);
if (ret)
@@ -468,8 +473,11 @@ static int s3c_adc_resume(struct platform_device *pdev)
clk_enable(adc-clk);
enable_irq(adc-irq);
 
-   writel(adc-prescale | S3C2410_ADCCON_PRSCEN,
-  adc-regs + S3C2410_ADCCON);
+   tmp = adc-prescale | S3C2410_ADCCON_PRSCEN;
+   /* Enable 12-bit ADC resolution */
+   if (platform_get_device_id(pdev)-driver_data != TYPE_ADCV1)
+   tmp |= S3C64XX_ADCCON_RESSEL;
+   writel(tmp, adc-regs + S3C2410_ADCCON);
 
return 0;
 }
@@ -494,16 +502,20 @@ static struct platform_device_id s3c_adc_driver_ids[] = {
 };
 MODULE_DEVICE_TABLE(platform, s3c_adc_driver_ids);
 
+static const struct dev_pm_ops adc_pm_ops = {
+   .suspend= s3c_adc_suspend,
+   .resume = s3c_adc_resume,
+};
+
 static struct platform_driver s3c_adc_driver = {
.id_table   = s3c_adc_driver_ids,
.driver = {
.name   = s3c-adc,
.owner  = THIS_MODULE,
+   .pm = adc_pm_ops,
},
.probe  = s3c_adc_probe,
.remove = __devexit_p(s3c_adc_remove),
-   .suspend= s3c_adc_suspend,
-   .resume = s3c_adc_resume,
 };
 
 static int __init adc_init(void)
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 5/6] ARM: S5PC110/S5PV210: Support ADC

[MyungJoo Ham]

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-s5pv210/cpu.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-s5pv210/cpu.c b/arch/arm/mach-s5pv210/cpu.c
index 61e6c24..79907ec 100644
--- a/arch/arm/mach-s5pv210/cpu.c
+++ b/arch/arm/mach-s5pv210/cpu.c
@@ -126,7 +126,7 @@ void __init s5pv210_map_io(void)
s5pv210_default_sdhci2();
s5pv210_default_sdhci3();
 
-   s3c_adc_setname(s3c64xx-adc);
+   s3c_adc_setname(samsung-adc-v3);
 
s3c_cfcon_setname(s5pv210-pata);
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 6/6] Samsung SoC: header file revised to prevent declaring duplicated.

[MyungJoo Ham]

There has been no #ifndef - #define - #endif protection for this header
file. The patch adds it for Exynos4-ADC support

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
---
 arch/arm/plat-samsung/include/plat/devs.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/devs.h 
b/arch/arm/plat-samsung/include/plat/devs.h
index 4af108f..3c87779 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -12,6 +12,9 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
+#ifndef __PLAT_DEVS_H
+#define __PLAT_DEVS_H __FILE__
+
 #include linux/platform_device.h
 
 struct s3c24xx_uart_resources {
@@ -159,3 +162,5 @@ extern struct platform_device s3c_device_ac97;
  */
 extern void *s3c_set_platdata(void *pd, size_t pdsize,
  struct platform_device *pdev);
+
+#endif /* __PLAT_DEVS_H */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 2/5] Samsung SoC ADC: Channel selection for S5PV210, S5PC110, and Exynos4

[MyungJoo Ham]

On Wed, Jun 29, 2011 at 10:42 PM, Kukjin Kim kgene@samsung.com wrote:
 MyungJoo Ham wrote:

 In S5PV210/S5PC110/Exynos4, ADCMUX channel selection uses ADCMUX
 register, not ADCCON register. This patch corrects the behavior of
 Samsung-ADC for such cpus.

 Signed-off-by: MyungJoo Ham myungjoo@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 --
 v2: No changes from v1. Resubmitted as a series of patches
 ---
[]

  enum s3c_cpu_type {
       TYPE_S3C24XX,
 -     TYPE_S3C64XX
 +     TYPE_S3C64XX,
 +     TYPE_S5P,
  };

 How about S5PC100? Following is better for next if we cannot distinguish it
 by CPU.

 -enum s3c_cpu_type {
 -       TYPE_S3C24XX,
 -       TYPE_S3C64XX
 +enum samsung_adc_type {
 +       TYPE_ADC24,      /* S3C24XX */
 +       TYPE_ADC64,      /* S3C64XX, S5P64X0, S5PC100 */
 +       TYPE_ADCV3      /* S5PV210, EXYNOS4210 */
  };
 ...

 TYPE_ADCV1 and V2?...
 Of course, the name can be changed...

I don't mind about these names as they are just internal values of adc.c.
Anyway, I prefer the last suggestion and I'll use TYPE_ADCV1/V2/V3.

Thanks.

-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 6/6] Exynos4 NURI: configure rtc-s3c.

[MyungJoo Ham]

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos4/mach-nuri.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/mach-nuri.c 
b/arch/arm/mach-exynos4/mach-nuri.c
index 0c9401c..bdf7a5c 100644
--- a/arch/arm/mach-exynos4/mach-nuri.c
+++ b/arch/arm/mach-exynos4/mach-nuri.c
@@ -1098,6 +1098,7 @@ static struct platform_device *nuri_devices[] __initdata 
= {
s3c_device_i2c3,
i2c9_gpio,
s3c_device_adc,
+   s3c_device_rtc,
 
/* NURI Devices */
nuri_gpio_keys,
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/6] ARM: EXYNOS4: NURI Board Configuration Update

[MyungJoo Ham]

1/6: Increase NR_IRQS for MAX8997
2/6: Add MAX8997 PMIC
3/6: Add MAX17042 Fuel Gauge
4/6: Add ADC
5/6: Add MAX8903 Secondary Charger
6/6: Add RTC-S3C

ps. Tushar, I didn't seperated MAX8997 support code out of mach-nuri.c, yet 
because I still have no idea about how similar the Origen board is with NURI 
board.

MyungJoo Ham (6):
  ARM: EXYNOS4: Increase NR_IRQS for devices with more IRQs
  Exynos4 NURI: configure regulators and PMIC (MAX8997)
  Exynos4 NURI: configure MAX17042 fuel gauge
  Exynos4 NURI: configure ADC.
  Exynos4 NURI: configure MAX8903 secondary charger
  Exynos4 NURI: configure rtc-s3c.

 arch/arm/mach-exynos4/include/mach/irqs.h |2 +-
 arch/arm/mach-exynos4/mach-nuri.c |  739 -
 2 files changed, 739 insertions(+), 2 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/6] ARM: EXYNOS4: Increase NR_IRQS for devices with more IRQs

[MyungJoo Ham]

MAX8997/17042, which are used by Exynos4-NURI, use additional IRQ
numbers after GPIO's IRQs. The patch creates some room for those
devices.

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos4/include/mach/irqs.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h 
b/arch/arm/mach-exynos4/include/mach/irqs.h
index 31f6bed..51b5db5 100644
--- a/arch/arm/mach-exynos4/include/mach/irqs.h
+++ b/arch/arm/mach-exynos4/include/mach/irqs.h
@@ -154,6 +154,6 @@
 #define IRQ_GPIO_END   (S5P_GPIOINT_BASE + S5P_GPIOINT_COUNT)
 
 /* Set the default NR_IRQS */
-#define NR_IRQS(IRQ_GPIO_END)
+#define NR_IRQS(IRQ_GPIO_END + 64)
 
 #endif /* __ASM_ARCH_IRQS_H */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/6] Exynos4 NURI: configure regulators and PMIC (MAX8997)

[MyungJoo Ham]

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

--
Changes from v3
- Updated init function name to include other power related devices.
Changes from v2
- Add more __initdata entries
- Moved and renamed pmic init function
- Rearranged init point of PMIC
Changes from v1
- Removed unnecessary initialization data
- Add __initdata where necessary
- Corrected a regulator name for ADC
---
 arch/arm/mach-exynos4/mach-nuri.c |  625 -
 1 files changed, 624 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos4/mach-nuri.c 
b/arch/arm/mach-exynos4/mach-nuri.c
index 642702b..ec51f5c 100644
--- a/arch/arm/mach-exynos4/mach-nuri.c
+++ b/arch/arm/mach-exynos4/mach-nuri.c
@@ -17,6 +17,7 @@
 #include linux/gpio.h
 #include linux/regulator/machine.h
 #include linux/regulator/fixed.h
+#include linux/mfd/max8997.h
 #include linux/mmc/host.h
 #include linux/fb.h
 #include linux/pwm_backlight.h
@@ -344,11 +345,629 @@ static void __init nuri_tsp_init(void)
s3c_gpio_setpull(gpio, S3C_GPIO_PULL_UP);
 }
 
+static struct regulator_consumer_supply __initdata max8997_ldo1_[] = {
+   REGULATOR_SUPPLY(vdd, s5p-adc), /* Used by CPU's ADC drv */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo3_[] = {
+   REGULATOR_SUPPLY(vdd11, s5p-mipi-csis.0), /* MIPI */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo4_[] = {
+   REGULATOR_SUPPLY(vdd18, s5p-mipi-csis.0), /* MIPI */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo5_[] = {
+   REGULATOR_SUPPLY(vhsic, modemctl), /* MODEM */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo7_[] = {
+   REGULATOR_SUPPLY(dig_18, 0-001f), /* HCD803 */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo8_[] = {
+   REGULATOR_SUPPLY(vusb_d, NULL), /* Used by CPU */
+   REGULATOR_SUPPLY(vdac, NULL), /* Used by CPU */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo11_[] = {
+   REGULATOR_SUPPLY(vcc, platform-lcd), /* U804 LVDS */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo12_[] = {
+   REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo13_[] = {
+   REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo14_[] = {
+   REGULATOR_SUPPLY(inmotor, max8997-haptic),
+};
+static struct regulator_consumer_supply __initdata max8997_ldo15_[] = {
+   REGULATOR_SUPPLY(avdd, 3-004a), /* Touch Screen */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo16_[] = {
+   REGULATOR_SUPPLY(d_sensor, 0-001f), /* HDC803 */
+};
+static struct regulator_consumer_supply __initdata max8997_ldo18_[] = {
+   REGULATOR_SUPPLY(vdd, 3-004a), /* Touch Screen */
+};
+static struct regulator_consumer_supply __initdata max8997_buck1_[] = {
+   REGULATOR_SUPPLY(vdd_arm, NULL), /* CPUFREQ */
+};
+static struct regulator_consumer_supply __initdata max8997_buck2_[] = {
+   REGULATOR_SUPPLY(vdd_int, NULL), /* CPUFREQ */
+};
+static struct regulator_consumer_supply __initdata max8997_buck3_[] = {
+   REGULATOR_SUPPLY(vdd, mali_dev.0), /* G3D of Exynos 4 */
+};
+static struct regulator_consumer_supply __initdata max8997_buck4_[] = {
+   REGULATOR_SUPPLY(core, 0-001f), /* HDC803 */
+};
+static struct regulator_consumer_supply __initdata max8997_buck6_[] = {
+   REGULATOR_SUPPLY(dig_28, 0-001f), /* pin 7 of HDC803 */
+};
+static struct regulator_consumer_supply __initdata max8997_esafeout1_[] = {
+   REGULATOR_SUPPLY(usb_vbus, NULL), /* CPU's USB OTG */
+};
+static struct regulator_consumer_supply __initdata max8997_esafeout2_[] = {
+   REGULATOR_SUPPLY(usb_vbus, modemctl), /* VBUS of Modem */
+};
+
+static struct regulator_consumer_supply __initdata max8997_charger_[] = {
+   REGULATOR_SUPPLY(vinchg1, charger-manager.0),
+};
+static struct regulator_consumer_supply __initdata max8997_chg_toff_[] = {
+   REGULATOR_SUPPLY(vinchg_stop, NULL), /* for jack interrupt handlers */
+};
+
+static struct regulator_consumer_supply __initdata max8997_32khz_ap_[] = {
+   REGULATOR_SUPPLY(gps_clk, bcm4751),
+   REGULATOR_SUPPLY(bt_clk, bcm4330-b1),
+   REGULATOR_SUPPLY(wifi_clk, bcm433-b1),
+};
+
+static struct regulator_init_data __initdata max8997_ldo1_data = {
+   .constraints= {
+   .name   = VADC_3.3V_C210,
+   .min_uV = 330,
+   .max_uV = 330,
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   .apply_uV   = 1,
+   .state_mem  = {
+   .disabled   = 1,
+   },
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(max8997_ldo1_),
+   .consumer_supplies  = max8997_ldo1_,
+};
+
+static struct regulator_init_data

[PATCH v3 4/6] Exynos4 NURI: configure ADC.

[MyungJoo Ham]

Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos4/mach-nuri.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/mach-nuri.c 
b/arch/arm/mach-exynos4/mach-nuri.c
index 2467a2a..e81e8ca 100644
--- a/arch/arm/mach-exynos4/mach-nuri.c
+++ b/arch/arm/mach-exynos4/mach-nuri.c
@@ -29,6 +29,7 @@
 #include asm/mach/arch.h
 #include asm/mach-types.h
 
+#include plat/adc.h
 #include plat/regs-serial.h
 #include plat/exynos4.h
 #include plat/cpu.h
@@ -1020,6 +1021,7 @@ static struct platform_device *nuri_devices[] __initdata 
= {
s5p_device_ehci,
s3c_device_i2c3,
i2c9_gpio,
+   s3c_device_adc,
 
/* NURI Devices */
nuri_gpio_keys,
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html