Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Andrzej Hajda]

On 05/01/2014 11:11 AM, Russell King - ARM Linux wrote:
 On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote:
 2. You replace calls of component_add and component_del with calls
 to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT,  
 specific_component_ops),
 or interface_tracker_ifdown.
 Thats all for components.
 How does the master get to decide which components are for it?

This is not a part of the framework. The master can construct
the list of its components anyhow. Some examples:
1. List of device tree video interface port nodes pointed by
master's remote-endpoint phandles.
2. List of device nodes pointed by supernode phandles.
3. Nodes pointed by other phandles in master's node.
4. Devices compatible with the list of drivers.

This is for create list of objects. As interface type it should
use the types of interface it expects at given nodes and is able to handle.

Small issue:
If the master creates list of devices and for particular interface
type expects DT node as the object, translation is easy: dev-of_node.
But if the situation is reverse kernel does not provide generic helper
for translating of_node to device, however kernel have everything to
provide such function if necessary.
Other solution is to use only DT nodes for object identification,
it will narrow the framework usage to DT architectures, but seems to be
more flexible anyway - we can have more than one interface of given type per
device, we can distinguish them by port node.

   As
 I see it, all masters see all components of a particular type.
 What if you have a system with two masters each of which are bound
 to a set of unique components but some of the components are of a
 the same type?

The master receives notifications only about interfaces he has
registered callback for. For example:
interface_tracker_register(node, INTERFACE_TRACKER_TYPE_DRM_PANEL, cb);

means that 'cb' callback will be called only if panel identifed by node
is up or down.
If the driver expect that at the 'node' there could be also component it
can also
listen for components:
interface_tracker_register(node, INTERFACE_TRACKER_TYPE_COMPONENT, cb);

Now 'cb' will be called if component or panel appears/disappears at node
'node'.

so callback function can look like:

void cb_func(struct interface_tracker_block *itb, const void *object,
unsigned long type, bool on,
  void *data)
{
struct priv_struct *priv = container_of(itb, struct priv_struct, itb);
switch(type) {
case INTERFACE_TRACKER_TYPE_DRM_PANEL:
handle_drm_panel(priv, data, on);
break;
case INTERFACE_TRACKER_TYPE_DRM_COMPONENT:
handle_drm_component(priv, data, object, on);
break;
}
}

where handlers can look like:

void handle_drm_panel(struct priv_struct *priv, struct drm_panel *panel,
bool on);
void handle_drm_component(struct priv_struct *priv, struct component_ops
*ops, struct device *dev, bool on);


 How does the master know what type to use?


It should use type which it expects at the given node.

Regards
Andrzej

--
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] misc: exynos-chipid: Add Exynos Chipid driver support

[Krzysztof Kozlowski]

On sob, 2014-05-03 at 15:11 +0900, Pankaj Dubey wrote:
 diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
 index 7eb4b69..48c8fb5 100644
 --- a/drivers/misc/Makefile
 +++ b/drivers/misc/Makefile
 @@ -55,3 +55,4 @@ obj-$(CONFIG_SRAM)  += sram.o
  obj-y+= mic/
  obj-$(CONFIG_GENWQE) += genwqe/
  obj-$(CONFIG_ECHO)   += echo/
 +obj-$(CONFIG_EXYNOS_CHIPID)  += exynos-chipid.o
 diff --git a/drivers/misc/exynos-chipid.c b/drivers/misc/exynos-chipid.c
 new file mode 100644
 index 000..eb23339
 --- /dev/null
 +++ b/drivers/misc/exynos-chipid.c
 @@ -0,0 +1,83 @@
 +/*
 + * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
 + * http://www.samsung.com/

I wonder why this is copyrighted in the future (2015)?

Best regards,
Krzysztof


--
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/5] add cpuidle support for Exynos5420

[Chander Kashyap]

Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores.

This patchset adds cpuidle support for Exynos5420 SoC based on
generic big.little cpuidle driver.

Tested on SMDK5420.

This patch set depends on:
1. [PATCH 0/5] MCPM backend for Exynos5420
   http://www.spinics.net/lists/arm-kernel/msg327923.html

2. [PATCH] arm: exynos: add generic function to calculate cpu number
   http://www.spinics.net/lists/linux-samsung-soc/msg29446.html
   http://www.spinics.net/lists/arm-kernel/msg324024.html

Changelog is in respective patches.
Chander Kashyap (5):
  driver: cpuidle-big-little: add of_device_id structure
  cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little
driver
  driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
  exynos: cpuidle: do not allow cpuidle registration for Exynos5420
  mcpm: exynos: populate suspend and powered_up callbacks

 arch/arm/mach-exynos/cpuidle.c   |3 +++
 arch/arm/mach-exynos/mcpm-exynos.c   |   34 ++
 drivers/cpuidle/Kconfig.arm  |2 +-
 drivers/cpuidle/cpuidle-big_little.c |   12 +++-
 4 files changed, 49 insertions(+), 2 deletions(-)

-- 
1.7.9.5

--
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/5] exynos: cpuidle: do not allow cpuidle registration for Exynos5420

[Chander Kashyap]

Exynos5420 is big.Little Soc. It uses cpuidle-big-litle generic cpuidle driver.
Hence do not allow exynos cpuidle driver registration for Exynos5420.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
---
 arch/arm/mach-exynos/cpuidle.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index c57cae0..242f75d 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -219,6 +219,9 @@ static int exynos_cpuidle_probe(struct platform_device 
*pdev)
int cpu_id, ret;
struct cpuidle_device *device;
 
+   if (soc_is_exynos5420())
+   return -ENODEV;
+
if (soc_is_exynos5250())
exynos5_core_down_clk();
 
-- 
1.7.9.5

--
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/5] mcpm: exynos: populate suspend and powered_up callbacks

[Chander Kashyap]

In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v3:
1. Removed coherance enablement after suspend failure.
2. Use generic function to poweron cpu.
changes in v2:
1. Fixed typo: enynos_pmu_cpunr to exynos_pmu_cpunr
 arch/arm/mach-exynos/mcpm-exynos.c |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
b/arch/arm/mach-exynos/mcpm-exynos.c
index d0f7461..6d4a907 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -256,10 +256,44 @@ static int exynos_power_down_finish(unsigned int cpu, 
unsigned int cluster)
return -ETIMEDOUT; /* timeout */
 }
 
+void exynos_powered_up(void)
+{
+   unsigned int mpidr, cpu, cluster;
+
+   mpidr = read_cpuid_mpidr();
+   cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+   cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+   arch_spin_lock(exynos_mcpm_lock);
+   if (cpu_use_count[cpu][cluster] == 0)
+   cpu_use_count[cpu][cluster] = 1;
+   arch_spin_unlock(exynos_mcpm_lock);
+}
+
+static void exynos_suspend(u64 residency)
+{
+   unsigned int mpidr, cpunr;
+
+   mpidr = read_cpuid_mpidr();
+   cpunr = exynos_pmu_cpunr(mpidr);
+
+   __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 0x1c);
+
+   exynos_power_down();
+
+   /*
+* Execution reaches here only if cpu did not power down.
+* Hence roll back the changes done in exynos_power_down function.
+   */
+   exynos_cpu_powerup(cpunr);
+}
+
 static const struct mcpm_platform_ops exynos_power_ops = {
.power_up   = exynos_power_up,
.power_down = exynos_power_down,
.power_down_finish  = exynos_power_down_finish,
+   .suspend= exynos_suspend,
+   .powered_up = exynos_powered_up,
 };
 
 static void __init exynos_mcpm_usage_count_init(void)
-- 
1.7.9.5

--
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/5] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420

[Chander Kashyap]

Add samsung,exynos5420 compatible string to initialize generic
big-little cpuidle driver for Exynos5420.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
---
Changes in v3:
1. Add compatible string to of_device_id table insted comparing 
directoly
Changes in v2: none

 drivers/cpuidle/cpuidle-big_little.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpuidle/cpuidle-big_little.c 
b/drivers/cpuidle/cpuidle-big_little.c
index 4cd02bd..344d79fa 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -165,6 +165,7 @@ static int __init bl_idle_driver_init(struct cpuidle_driver 
*drv, int cpu_id)
 
 static const struct of_device_id compatible_machine_match[] = {
{ .compatible = arm,vexpress,v2p-ca15_a7 },
+   { .compatible = samsung,exynos5420 },
{},
 };
 
-- 
1.7.9.5

--
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/5] cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver

[Chander Kashyap]

Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores.
In order to use generic cpuidle-big-little driver, this patch adds Exynos5420
specific check to initialize generic cpuidle driver.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v3: None
Changes in v2:
1. Changed config macro from SOC_EXYNOS5420 to SOC_EXYNOS5420
 drivers/cpuidle/Kconfig.arm |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 97ccc31..d9596e7 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -4,7 +4,7 @@
 
 config ARM_BIG_LITTLE_CPUIDLE
bool Support for ARM big.LITTLE processors
-   depends on ARCH_VEXPRESS_TC2_PM
+   depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS
select ARM_CPU_SUSPEND
select CPU_IDLE_MULTIPLE_DRIVERS
help
-- 
1.7.9.5

--
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/5] driver: cpuidle-big-little: add of_device_id structure

[Chander Kashyap]

This driver will be used by many big.Little Soc's. As of now it does
string matching of hardcoded compatible string to init the driver. This
comparison list will keep on growing with addition of new SoC's.
Hence add of_device_id structure to collect the compatible strings of
SoC's using this driver.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
 drivers/cpuidle/cpuidle-big_little.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/cpuidle-big_little.c 
b/drivers/cpuidle/cpuidle-big_little.c
index b45fc62..4cd02bd 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -163,14 +163,23 @@ static int __init bl_idle_driver_init(struct 
cpuidle_driver *drv, int cpu_id)
return 0;
 }
 
+static const struct of_device_id compatible_machine_match[] = {
+   { .compatible = arm,vexpress,v2p-ca15_a7 },
+   {},
+};
+
 static int __init bl_idle_init(void)
 {
int ret;
+   struct device_node *root = of_find_node_by_path(/);
+
+   if (!root)
+   return -ENODEV;
 
/*
 * Initialize the driver just for a compliant set of machines
 */
-   if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7))
+   if (!of_match_node(compatible_machine_match, root))
return -ENODEV;
/*
 * For now the differentiation between little and big cores
-- 
1.7.9.5

--
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 2/5] cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver

[Andreas Färber]

Hi,

Am 05.05.2014 10:27, schrieb Chander Kashyap:
 Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores.
 In order to use generic cpuidle-big-little driver, this patch adds Exynos5420
 specific check to initialize generic cpuidle driver.
 
 Signed-off-by: Chander Kashyap chander.kash...@linaro.org
 Signed-off-by: Chander Kashyap k.chan...@samsung.com
 ---
 Changes in v3: None
 Changes in v2:
   1. Changed config macro from SOC_EXYNOS5420 to SOC_EXYNOS5420

This is probably a copypasto? Anyway, the commit message needs an
update since no Exynos5420 specific check is done below afaics. That
went into 3/5.

Cheers,
Andreas

  drivers/cpuidle/Kconfig.arm |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
 index 97ccc31..d9596e7 100644
 --- a/drivers/cpuidle/Kconfig.arm
 +++ b/drivers/cpuidle/Kconfig.arm
 @@ -4,7 +4,7 @@
  
  config ARM_BIG_LITTLE_CPUIDLE
   bool Support for ARM big.LITTLE processors
 - depends on ARCH_VEXPRESS_TC2_PM
 + depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS
   select ARM_CPU_SUSPEND
   select CPU_IDLE_MULTIPLE_DRIVERS
   help
 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 0/4] Introducing Exynos ChipId driver

[Pankaj Dubey]

Hi Arnd,

Thanks for review and suggestions.

On 05/04/2014 12:02 AM, Arnd Bergmann wrote:

On Saturday 03 May 2014 15:11:36 Pankaj Dubey wrote:

This patch series attempts to get rid of soc_is_exynos macros
and eventually with the help of this series we can probably get
rid of CONFIG_SOC_EXYNOS in near future.
Each Exynos SoC has ChipID block which can give information about
SoC's product Id and revision number. Currently we have single
DT binding information for this as samsung,exynos4210-chipid.
But Exynos4 and Exynos5 SoC series have one small difference in
chip Id, with resepect to product id bit-masks. So it means we
should have separate compatible string for these different series
of SoCs. So I have created new binding information for handling
this difference. Also currently I can think of putting this driver
code under drivers/misc/ but suggestions are welcome.
Also current form of driver is missing platfrom driver and needs
init function to be called from machine file (either exynos.c or
platsmp.c). I hope lot of suggestions and comments to improve this
further.

This patch series is based on Kukjin Kim's for-next (3.14_rc1 tag)
and prepared on top of following patch series and it's dependent
patch series.

I think putting it into drivers/soc would be most appropriate.
We already have a few drivers lined up that we want in there,
although the directory currently doesn't exist.

OK. Will move to drivers/soc. I can see already some patches
have been posted [1] by Andy Gross for creating directory
drivers/soc I will use those patches for adding samsung folder
under drivers/soc.

[1]: https://lkml.org/lkml/2014/4/21/46



However, I would ask that you use the infrastructure provided by
drivers/base/soc.c when you add this driver, to also make the
information available to user space using a standard API.


OK. Will update in next version.



Ideally this should be done by slightly restructuring the DT
source to make all on-chip devices appear below the soc node.


Currently I can't see soc nodes in exynos4 and exynos5 DT files.
So isn't it should be a separate patch first to modify all exynos4
exynos5 DT files to move all devices under soc node?
In that case existing chipid node will be also moved under soc node.


We'd have to think a bit about how to best do this while
preserving compatibility with existing dts files.


Is it necessary in this case?
As I have mentioned there is difference in bit-mask among exynos4
and exynos5's chipid. So is this reason not sufficient to keep separate
compatible for both?
Also even if we get some way to preserve existing compatibility, I afraid
in chipid driver that implementation will not look good, at least I am not
able to think of any good way. Any suggestions?



Regarding patch 4, this is not what I meant when I asked for
removing the soc_is_exynos* macros. You basically do a 1:1 replacement
using a different interface, but you still have code that does
things differently based on a global identification.

I agree with what you are trying to say. But if you see recently we had some
patches (cpu_idle.c: [2], pmu.c: [3])  to remove usage of such macros from
exynos machine files. So only leftover files using these macros are exynos.c
platsmp.c and pm.c.

For exynos.c I have tried to remove soc_is_exynos4/exynos5 by matching with
compatible string in patch 1 of this series. Please let me know if that is OK?

Also for platsmp.c and pm.c I can think of following approaches
1: Keep these macros till we get generic solution?
2: Allow chipid driver to expose APIs to check SoC id and SoC revisions 
till we get

generic solution. So that at least we can remove #ifdef  based macros
as soc_is_exynosXYZ.
3: Use of of_flat_dt_is_compatible or similar APIs in these machine files 
till we get

generic solution. For some cases where we want to know SoC revision let us
map chipid register and get revision there itself.

Please let me know what approach you think will be good?

[2]: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/29085
[3]: https://lkml.org/lkml/2014/5/2/612

The only user left in device drivers is now the cpufreq driver,
which is going to be replaced anyway, so that is ok. Having
a global variable that is accessible to random device drivers
is probably not a good idea though, it will just lead to
bad coding in drivers again.

To give an example of how I think it should really be restructured,
let's look at one function:

static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
 { 76, BIT(1) }, /* RTC alarm */
 { 77, BIT(2) }, /* RTC tick */
 { /* sentinel */ },
};

static const struct exynos_wkup_irq exynos5250_wkup_irq[] = {
 { 75, BIT(1) }, /* RTC alarm */
 { 76, BIT(2) }, /* RTC tick */
 { /* sentinel */ },
};

static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
{
 const struct exynos_wkup_irq *wkup_irq;

 if (soc_is_exynos5250())
 wkup_irq 

Re: [Patch v3 2/5] cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver

[Chander Kashyap]

Hi Andreas,

On 5 May 2014 14:29, Andreas Färber afaer...@suse.de wrote:
 Hi,

 Am 05.05.2014 10:27, schrieb Chander Kashyap:
 Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores.
 In order to use generic cpuidle-big-little driver, this patch adds Exynos5420
 specific check to initialize generic cpuidle driver.

 Signed-off-by: Chander Kashyap chander.kash...@linaro.org
 Signed-off-by: Chander Kashyap k.chan...@samsung.com
 ---
 Changes in v3: None
 Changes in v2:
   1. Changed config macro from SOC_EXYNOS5420 to SOC_EXYNOS5420

 This is probably a copypasto? Anyway, the commit message needs an
 update since no Exynos5420 specific check is done below afaics. That
 went into 3/5.

Oops that's write,
Copy paste mistake, and commit message change is required. I will fix it .

Thanks



 Cheers,
 Andreas

  drivers/cpuidle/Kconfig.arm |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
 index 97ccc31..d9596e7 100644
 --- a/drivers/cpuidle/Kconfig.arm
 +++ b/drivers/cpuidle/Kconfig.arm
 @@ -4,7 +4,7 @@

  config ARM_BIG_LITTLE_CPUIDLE
   bool Support for ARM big.LITTLE processors
 - depends on ARCH_VEXPRESS_TC2_PM
 + depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS
   select ARM_CPU_SUSPEND
   select CPU_IDLE_MULTIPLE_DRIVERS
   help



 --
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



-- 
with warm regards,
Chander Kashyap
--
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] misc: exynos-chipid: Add Exynos Chipid driver support

[Pankaj Dubey]

On 05/05/2014 04:57 PM, Krzysztof Kozlowski wrote:

On sob, 2014-05-03 at 15:11 +0900, Pankaj Dubey wrote:

diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7eb4b69..48c8fb5 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_SRAM)+= sram.o
  obj-y += mic/
  obj-$(CONFIG_GENWQE)  += genwqe/
  obj-$(CONFIG_ECHO)+= echo/
+obj-$(CONFIG_EXYNOS_CHIPID)+= exynos-chipid.o
diff --git a/drivers/misc/exynos-chipid.c b/drivers/misc/exynos-chipid.c
new file mode 100644
index 000..eb23339
--- /dev/null
+++ b/drivers/misc/exynos-chipid.c
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
+ *   http://www.samsung.com/

I wonder why this is copyrighted in the future (2015)?


Thanks for pointing out, will correct it in next version.



Best regards,
Krzysztof






--
Best Regards,
Pankaj Dubey

--
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 v4 0/2] Add peach-pit board support

[Arun Kumar K]

Dependencies

Adding pwm nodes for backlight
https://patchwork.kernel.org/patch/4101881/

Changes from v3
--
- Addressed comments from Tomasz and Doug.

Changes from v2
--
- Use reference based node addressing in board dts file
  as suggested by Tomasz.
- Included patch to update 5420.dtsi with node references
  for all existing nodes.

Changes from v1
--
- Addressed review comments from Doug, Sachin  Tushar
- Removed adc and lid-switch nodes

Arun Kumar K (2):
  ARM: dts: Add node labels to 5420
  ARM: dts: Add peach-pit board support

 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts |  147 
 arch/arm/boot/dts/exynos5420.dtsi  |   26 ++---
 3 files changed, 161 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts

-- 
1.7.9.5

--
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 v4 1/2] ARM: dts: Add node labels to 5420

[Arun Kumar K]

Adding labels to nodes which do not have it yet
in exynos5420.dtsi. This is done so as to use reference
based node updation in board files.

Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
 arch/arm/boot/dts/exynos5420.dtsi |   26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..0d1dea8 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -125,7 +125,7 @@
clock-names = pll_ref, pll_in, sclk_audio, sclk_pcm_in;
};
 
-   codec@1100 {
+   mfc: codec@1100 {
compatible = samsung,mfc-v7;
reg = 0x1100 0x1;
interrupts = 0 96 0;
@@ -169,7 +169,7 @@
status = disabled;
};
 
-   mct@101C {
+   mct: mct@101C {
compatible = samsung,exynos4210-mct;
reg = 0x101C 0x800;
interrupt-controller;
@@ -270,7 +270,7 @@
interrupts = 0 47 0;
};
 
-   rtc@101E {
+   rtc: rtc@101E {
clocks = clock CLK_RTC;
clock-names = rtc;
status = disabled;
@@ -430,22 +430,22 @@
status = disabled;
};
 
-   serial@12C0 {
+   uart_0: serial@12C0 {
clocks = clock CLK_UART0, clock CLK_SCLK_UART0;
clock-names = uart, clk_uart_baud0;
};
 
-   serial@12C1 {
+   uart_1: serial@12C1 {
clocks = clock CLK_UART1, clock CLK_SCLK_UART1;
clock-names = uart, clk_uart_baud0;
};
 
-   serial@12C2 {
+   uart_2: serial@12C2 {
clocks = clock CLK_UART2, clock CLK_SCLK_UART2;
clock-names = uart, clk_uart_baud0;
};
 
-   serial@12C3 {
+   uart_3: serial@12C3 {
clocks = clock CLK_UART3, clock CLK_SCLK_UART3;
clock-names = uart, clk_uart_baud0;
};
@@ -465,14 +465,14 @@
#phy-cells = 0;
};
 
-   dp-controller@145B {
+   dp: dp-controller@145B {
clocks = clock CLK_DP1;
clock-names = dp;
phys = dp_phy;
phy-names = dp;
};
 
-   fimd@1440 {
+   fimd: fimd@1440 {
samsung,power-domain = disp_pd;
clocks = clock CLK_SCLK_FIMD1, clock CLK_FIMD1;
clock-names = sclk_fimd, fimd;
@@ -632,7 +632,7 @@
status = disabled;
};
 
-   hdmi@1453 {
+   hdmi: hdmi@1453 {
compatible = samsung,exynos4212-hdmi;
reg = 0x1453 0x7;
interrupts = 0 95 0;
@@ -644,7 +644,7 @@
status = disabled;
};
 
-   mixer@1445 {
+   mixer: mixer@1445 {
compatible = samsung,exynos5420-mixer;
reg = 0x1445 0x1;
interrupts = 0 94 0;
@@ -715,7 +715,7 @@
clock-names = tmu_apbif, tmu_triminfo_apbif;
};
 
-watchdog@101D {
+watchdog: watchdog@101D {
compatible = samsung,exynos5420-wdt;
reg = 0x101D 0x100;
interrupts = 0 42 0;
@@ -724,7 +724,7 @@
samsung,syscon-phandle = pmu_system_controller;
 };
 
-   sss@1083 {
+   sss: sss@1083 {
compatible = samsung,exynos4210-secss;
reg = 0x1083 0x1;
interrupts = 0 112 0;
-- 
1.7.9.5

--
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 v4 2/2] ARM: dts: Add peach-pit board support

[Arun Kumar K]

Adds the google peach-pit board dts file which uses
exynos5420 SoC.

Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts |  147 
 2 files changed, 148 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..3220e29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+   exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..fae33dd
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,147 @@
+/*
+ * Google Peach Pit Rev 6+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include dt-bindings/input/input.h
+#include dt-bindings/gpio/gpio.h
+#include exynos5420.dtsi
+
+/ {
+   model = Google Peach Pit Rev 6+;
+
+   compatible = google,pit-rev16,
+   google,pit-rev15, google,pit-rev14,
+   google,pit-rev13, google,pit-rev12,
+   google,pit-rev11, google,pit-rev10,
+   google,pit-rev9, google,pit-rev8,
+   google,pit-rev7, google,pit-rev6,
+   google,pit, google,peach,samsung,exynos5420,
+   samsung,exynos5;
+
+   memory {
+   reg = 0x2000 0x8000;
+   };
+
+   fixed-rate-clocks {
+   oscclk {
+   compatible = samsung,exynos5420-oscclk;
+   clock-frequency = 2400;
+   };
+   };
+
+   gpio-keys {
+   compatible = gpio-keys;
+
+   pinctrl-names = default;
+   pinctrl-0 = power_key_irq;
+
+   power {
+   label = Power;
+   gpios = gpx1 2 GPIO_ACTIVE_LOW;
+   linux,code = KEY_POWER;
+   gpio-key,wakeup;
+   };
+   };
+
+   backlight {
+   compatible = pwm-backlight;
+   pwms = pwm 0 100 0;
+   brightness-levels = 0 100 500 1000 1500 2000 2500 2800;
+   default-brightness-level = 7;
+   pinctrl-0 = pwm0_out;
+   pinctrl-names = default;
+   };
+};
+
+pinctrl_0 {
+   tpm_irq: tpm-irq {
+   samsung,pins = gpx1-0;
+   samsung,pin-function = 0;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   power_key_irq: power-key-irq {
+   samsung,pins = gpx1-2;
+   samsung,pin-function = 0;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+};
+
+rtc {
+   status = okay;
+};
+
+uart_3 {
+   status = okay;
+};
+
+mmc_0 {
+   status = okay;
+   num-slots = 1;
+   broken-cd;
+   caps2-mmc-hs200-1_8v;
+   supports-highspeed;
+   non-removable;
+   card-detect-delay = 200;
+   clock-frequency = 4;
+   samsung,dw-mshc-ciu-div = 3;
+   samsung,dw-mshc-sdr-timing = 0 4;
+   samsung,dw-mshc-ddr-timing = 0 2;
+   pinctrl-names = default;
+   pinctrl-0 = sd0_clk sd0_cmd sd0_bus4 sd0_bus8;
+
+   slot@0 {
+   reg = 0;
+   bus-width = 8;
+   };
+};
+
+mmc_2 {
+   status = okay;
+   num-slots = 1;
+   supports-highspeed;
+   card-detect-delay = 200;
+   clock-frequency = 4;
+   samsung,dw-mshc-ciu-div = 3;
+   samsung,dw-mshc-sdr-timing = 2 3;
+   samsung,dw-mshc-ddr-timing = 1 2;
+   pinctrl-names = default;
+   pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
+
+   slot@0 {
+   reg = 0;
+   bus-width = 4;
+   };
+};
+
+hsi2c_9 {
+   status = okay;
+   clock-frequency = 40;
+
+   tpm@20 {
+   compatible = infineon,slb9645tt;
+   reg = 0x20;
+
+   /* Unused irq; but still need to configure the pins */
+   pinctrl-names = default;
+   pinctrl-0 = tpm_irq;
+   };
+};
+
+/*
+ * Use longest HW watchdog in SoC (32 seconds) since the hardware
+ * watchdog provides no debugging information (compared to soft/hard
+ * lockup detectors) and so should be last resort.
+ */
+watchdog {
+   timeout-sec = 32;
+};
-- 
1.7.9.5

--
To 

Re: exynos4412: porting hdmiddc and hdmiphy node entries

[Tomasz Stanislawski]

Hi Tobias,
Sorry for a late reply.
Please refer to the comments below.

On 04/27/2014 02:33 AM, Tobias Jakobi wrote:
 Hello,
 
 I'm trying to get the HDMI port working on a Exynos4412 based board.
 Attached is a snippet of a dts. This config was supposed to work in
 the past.
 
 However with 3.15-rc1 some things changed. samsung,exynos4210-hdmiddc
 and samsung,exynos4212-hdmiphy have no function anymore, the code that
 previously handled these compatible strings is gone.
 
 So, it looks like that without some patching, HDMI support is atm broken.
 
 I have applied these:
 http://www.spinics.net/lists/linux-samsung-soc/msg28161.html
 http://www.spinics.net/lists/linux-samsung-soc/msg28259.html
 
 With the first one I can drop a clock from the hdmi node. But then
 trouble starts.
 
 So, first of all I'm unsure what the 'hdmiddc' node should be converted
 to. Documentation (exynos_hdmi.txt) doesn't help here, since it just
 says phandle to the hdmi ddc node. What kind of 'hdmi ddc node'? From
 the code it looks like that it should point to an i2c adapter now. So
 should it point to 'i2c_2' now?

The spec is wrong. It should be a handle to I2C adapter.
The semantics of this node was changed in patch
drm/exynos: hdmi: use i2c_adapter instead of i2c_client
8fa04aae2aa8bafcfc027856904ebee0060506d0

 
 The second thing is 'phy', which should be a phandle to the hdmi ddc
 node. Again, no idea what that node should be. Apparantly such nodes
 can't be created with current kernel code anyway, primary reason to
 apply the simply-phy patches.

The meaning of hdmiphy is ambiguous.
In exynos4 spec there are _TWO_ components named HDMIPHY.
The first one is a PLL that generates a clock for HDMI subsystem.
This PLL is controlled by I2C.

You can find an example of its bindings at:
http://lists.freedesktop.org/archives/dri-devel/2013-October/047687.html


The second one is HDMI's physical interface located in PMU unit.

The exynos-simple-phy is dedicated to controller the former (component of PMU).

The 'phy' attribute in DT refers to the PLL.
There is a debate if 'phy' should refer to I2C device itself or
rather to I2C bus. Currently it refers to driverless instance
of I2C device.

 
 OK, so I have to put a simple-phys node in my dts now. Or, wait, do I
 just replace the hdmiphy node with a simple-phys node?
 
 Would look something like this:
 hdmiphy: simple-phys@38 {
   compatible = samsung,exynos4412-simple-phy;
   reg = 0x38 0x1;
   #phy-cells = 1;
 };
 
 Somehow this doesn't look right. And indeed:
 https://patchwork.kernel.org/patch/4021121/
 
 At least for exynos5250 this node is not a child on an i2c adapter.

This is a completely different HDMIPHY.

 
 And yes, I would still have to add 'phys' and 'phy-names' to the hdmi
 node. This looks wrong again. Why do I have to specify 'phys' when I
 already have 'phy' there? Isn't that redundant?

'phys' and 'phy-names' refers to PHY interfaces delivered by phy-core.
The attribute named 'phy' refers to I2C device used to controller HDMI's PLL.
The naming convention is very misleading.

 
 Well, you see, lots of confusion here. I would appreciate any kind of
 help on how to proceed here.

The documentation for HDMI's bindings should be fixed.

 
 With best wishes,
 Tobias
 

Regards,
Tomasz Stanislawski

--
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 v4 0/5] add cpuidle support for Exynos5420

[Chander Kashyap]

Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores.

This patchset adds cpuidle support for Exynos5420 SoC based on
generic big.little cpuidle driver.

Tested on SMDK5420.

This patch set depends on:
1. [PATCH 0/5] MCPM backend for Exynos5420
   http://www.spinics.net/lists/arm-kernel/msg327923.html

2. [PATCH] arm: exynos: add generic function to calculate cpu number
   http://www.spinics.net/lists/linux-samsung-soc/msg29446.html
   http://www.spinics.net/lists/arm-kernel/msg324024.html

Changelog is in respective patches.
Chander Kashyap (5):
  driver: cpuidle-big-little: add of_device_id structure
  cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little
driver
  driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
  exynos: cpuidle: do not allow cpuidle registration for Exynos5420
  mcpm: exynos: populate suspend and powered_up callbacks

 arch/arm/mach-exynos/cpuidle.c   |3 +++
 arch/arm/mach-exynos/mcpm-exynos.c   |   34 ++
 drivers/cpuidle/Kconfig.arm  |2 +-
 drivers/cpuidle/cpuidle-big_little.c |   12 +++-
 4 files changed, 49 insertions(+), 2 deletions(-)

-- 
1.7.9.5

--
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 v4 1/5] driver: cpuidle-big-little: add of_device_id structure

[Chander Kashyap]

This driver will be used by many big.Little Soc's. As of now it does
string matching of hardcoded compatible string to init the driver. This
comparison list will keep on growing with addition of new SoC's.
Hence add of_device_id structure to collect the compatible strings of
SoC's using this driver.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
 drivers/cpuidle/cpuidle-big_little.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/cpuidle-big_little.c 
b/drivers/cpuidle/cpuidle-big_little.c
index b45fc62..4cd02bd 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -163,14 +163,23 @@ static int __init bl_idle_driver_init(struct 
cpuidle_driver *drv, int cpu_id)
return 0;
 }
 
+static const struct of_device_id compatible_machine_match[] = {
+   { .compatible = arm,vexpress,v2p-ca15_a7 },
+   {},
+};
+
 static int __init bl_idle_init(void)
 {
int ret;
+   struct device_node *root = of_find_node_by_path(/);
+
+   if (!root)
+   return -ENODEV;
 
/*
 * Initialize the driver just for a compliant set of machines
 */
-   if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7))
+   if (!of_match_node(compatible_machine_match, root))
return -ENODEV;
/*
 * For now the differentiation between little and big cores
-- 
1.7.9.5

--
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 v4 2/5] cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver

[Chander Kashyap]

Add support to select generic big-little cpuidle driver for Samsung Exynos
series SoC's. This is required for Exynos big-llittle SoC's eg, Exynos5420.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v4:
1. Typo fixed from SOC_EXYNOS5420 to ARCH_EXYNOS
2. Commit message updated
Changes in v3: None
Changes in v2:
1. Changed config macro from SOC_EXYNOS5420 to ARCH_EXYNOS
 drivers/cpuidle/Kconfig.arm |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 97ccc31..d9596e7 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -4,7 +4,7 @@
 
 config ARM_BIG_LITTLE_CPUIDLE
bool Support for ARM big.LITTLE processors
-   depends on ARCH_VEXPRESS_TC2_PM
+   depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS
select ARM_CPU_SUSPEND
select CPU_IDLE_MULTIPLE_DRIVERS
help
-- 
1.7.9.5

--
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 v4 3/5] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420

[Chander Kashyap]

Add samsung,exynos5420 compatible string to initialize generic
big-little cpuidle driver for Exynos5420.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
---
Changes in v4: None
Changes in v3:
1. Add compatible string to of_device_id table insted comparing 
directoly
Changes in v2: none

 drivers/cpuidle/cpuidle-big_little.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpuidle/cpuidle-big_little.c 
b/drivers/cpuidle/cpuidle-big_little.c
index 4cd02bd..344d79fa 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -165,6 +165,7 @@ static int __init bl_idle_driver_init(struct cpuidle_driver 
*drv, int cpu_id)
 
 static const struct of_device_id compatible_machine_match[] = {
{ .compatible = arm,vexpress,v2p-ca15_a7 },
+   { .compatible = samsung,exynos5420 },
{},
 };
 
-- 
1.7.9.5

--
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 v4 4/5] exynos: cpuidle: do not allow cpuidle registration for Exynos5420

[Chander Kashyap]

Exynos5420 is big.Little Soc. It uses cpuidle-big-litle generic cpuidle driver.
Hence do not allow exynos cpuidle driver registration for Exynos5420.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
---
 arch/arm/mach-exynos/cpuidle.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index c57cae0..242f75d 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -219,6 +219,9 @@ static int exynos_cpuidle_probe(struct platform_device 
*pdev)
int cpu_id, ret;
struct cpuidle_device *device;
 
+   if (soc_is_exynos5420())
+   return -ENODEV;
+
if (soc_is_exynos5250())
exynos5_core_down_clk();
 
-- 
1.7.9.5

--
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 v4 5/5] mcpm: exynos: populate suspend and powered_up callbacks

[Chander Kashyap]

In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v4: None
Changes in v3:
1. Removed coherancy enablement after suspend failure.
2. Use generic function to poweron cpu.
changes in v2:
1. Fixed typo: enynos_pmu_cpunr to exynos_pmu_cpunr
 arch/arm/mach-exynos/mcpm-exynos.c |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
b/arch/arm/mach-exynos/mcpm-exynos.c
index d0f7461..6d4a907 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -256,10 +256,44 @@ static int exynos_power_down_finish(unsigned int cpu, 
unsigned int cluster)
return -ETIMEDOUT; /* timeout */
 }
 
+void exynos_powered_up(void)
+{
+   unsigned int mpidr, cpu, cluster;
+
+   mpidr = read_cpuid_mpidr();
+   cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+   cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+   arch_spin_lock(exynos_mcpm_lock);
+   if (cpu_use_count[cpu][cluster] == 0)
+   cpu_use_count[cpu][cluster] = 1;
+   arch_spin_unlock(exynos_mcpm_lock);
+}
+
+static void exynos_suspend(u64 residency)
+{
+   unsigned int mpidr, cpunr;
+
+   mpidr = read_cpuid_mpidr();
+   cpunr = exynos_pmu_cpunr(mpidr);
+
+   __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 0x1c);
+
+   exynos_power_down();
+
+   /*
+* Execution reaches here only if cpu did not power down.
+* Hence roll back the changes done in exynos_power_down function.
+   */
+   exynos_cpu_powerup(cpunr);
+}
+
 static const struct mcpm_platform_ops exynos_power_ops = {
.power_up   = exynos_power_up,
.power_down = exynos_power_down,
.power_down_finish  = exynos_power_down_finish,
+   .suspend= exynos_suspend,
+   .powered_up = exynos_powered_up,
 };
 
 static void __init exynos_mcpm_usage_count_init(void)
-- 
1.7.9.5

--
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: [PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Kishon Vijay Abraham I]

Hi,

On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote:
 Hi,
 
 On 09/04/14 11:12, Rahul Sharma wrote:
 Idea looks good. How about keeping compatible which is independent
 of SoC, something like samsung,exynos-simple-phy and provide Reg
 and Bit through phy provider node. This way we can avoid SoC specific
 hardcoding in phy driver and don't need to look into dt bindings for
 each new SoC.
 
 I believe it is a not recommended approach.

Why not? We should try to avoid hard coding in the driver code. Moreover by
avoiding hardcoding we can make it a generic driver for single bit PHYs.

Cheers
Kishon
--
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 1/2] v4l: Add resolution change event.

[Arun Kumar K]

Hi Hans,

On Wed, Apr 30, 2014 at 8:03 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 On 04/30/2014 12:38 PM, Arun Kumar K wrote:
 Hi Hans,


 On 04/22/14 18:22, Hans Verkuil wrote:
 On 04/21/2014 11:26 AM, Arun Kumar K wrote:
 From: Pawel Osciak posc...@chromium.org

 This event indicates that the decoder has reached a point in the stream,
 at which the resolution changes. The userspace is expected to provide a new
 set of CAPTURE buffers for the new format before decoding can continue.
 The event can also be used for more generic events involving resolution
 or format changes at runtime for all kinds of video devices.

 Signed-off-by: Pawel Osciak posc...@chromium.org
 Signed-off-by: Arun Kumar K arun...@samsung.com
 ---
  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   16 
  include/uapi/linux/videodev2.h |6 ++
  2 files changed, 22 insertions(+)

 diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
 b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 index 5c70b61..0aec831 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 @@ -155,6 +155,22 @@
 /entry
   /row
   row
 +   entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
 +   entry5/entry
 +   entry
 + paraThis event is triggered when a resolution or format change
 +  is detected during runtime by the video device. It can be a
 +  runtime resolution change triggered by a video decoder or the
 +  format change happening on an HDMI connector. Application may
 +  need to reinitialize buffers before proceeding further./para
 +
 +  paraThis event has a v4l2-event-source-change; associated
 + with it. This has significance only for v4l2 subdevs where the
 + structfieldpad_num/structfield field will be updated with
 + the pad number on which the event is triggered./para
 +   /entry
 + /row
 + row
 entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
 entry0x0800/entry
 entryBase event number for driver-private events./entry
 diff --git a/include/uapi/linux/videodev2.h 
 b/include/uapi/linux/videodev2.h
 index 6ae7bbe..12e0614 100644
 --- a/include/uapi/linux/videodev2.h
 +++ b/include/uapi/linux/videodev2.h
 @@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
  #define V4L2_EVENT_EOS 2
  #define V4L2_EVENT_CTRL3
  #define V4L2_EVENT_FRAME_SYNC  4
 +#define V4L2_EVENT_SOURCE_CHANGE   5
  #define V4L2_EVENT_PRIVATE_START   0x0800

  /* Payload for V4L2_EVENT_VSYNC */
 @@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
 __u32 frame_sequence;
  };

 +struct v4l2_event_source_change {
 +   __u32 pad_num;
 +};
 +
  struct v4l2_event {
 __u32   type;
 union {
 struct v4l2_event_vsync vsync;
 struct v4l2_event_ctrl  ctrl;
 struct v4l2_event_frame_syncframe_sync;
 +   struct v4l2_event_source_change source_change;
 __u8data[64];
 } u;
 __u32   pending;


 This needs to be done differently. The problem is that you really have 
 multiple
 events that you want to subscribe to: one for each pad (or input: see the 
 way
 VIDIOC_G/S_EDID maps pad to an input or output index when used with a video 
 node,
 we have to support that for this event as well).

 What you want to do is similar to what is done for control events: there 
 you can
 subscribe for a specific control and get notified when that control changes.

 The way that works in the event code is that the 'id' field in the 
 v4l2_event
 struct contains that control ID, or, in this case, the pad/input/output 
 index.


 As I am new to v4l2-events itself, I might have some noob questions.
 I understood filling pad index into id field. But for video nodes,
 the application is supposed to put v4l2_buf_type in the id field?

 No, a capture video node can have multiple inputs (those are enumerated with
 VIDIOC_ENUMINPUTS), and each input can generate a SOURCE_CHANGE event, even 
 if it
 is not the currently active input. Hence the need of setting id to the input
 index. v4l2_buf_type makes no sense here.


Ok. But in a simple m2m device like mfc, the userspace has to subscribe to
the event say on the CAPTURE plane where buffers has to be re-allocated on
resolution change. So in such a case, what should be put in id field?


 In the application you will subscribe to the SOURCE_CHANGE event for a 
 specific
 pad/input/output index.

 In other words, the pad_num field should be dropped and the id field used
 instead.

 Assuming we will also add a 'changes' field (see my reply to the other post
 on that topic), then you should also provide replace and 

Re: [PATCH v2 1/2] v4l: Add resolution change event.

[Hans Verkuil]

On 05/05/2014 11:50 AM, Arun Kumar K wrote:
 Hi Hans,
 
 On Wed, Apr 30, 2014 at 8:03 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 On 04/30/2014 12:38 PM, Arun Kumar K wrote:
 Hi Hans,


 On 04/22/14 18:22, Hans Verkuil wrote:
 On 04/21/2014 11:26 AM, Arun Kumar K wrote:
 From: Pawel Osciak posc...@chromium.org

 This event indicates that the decoder has reached a point in the stream,
 at which the resolution changes. The userspace is expected to provide a 
 new
 set of CAPTURE buffers for the new format before decoding can continue.
 The event can also be used for more generic events involving resolution
 or format changes at runtime for all kinds of video devices.

 Signed-off-by: Pawel Osciak posc...@chromium.org
 Signed-off-by: Arun Kumar K arun...@samsung.com
 ---
  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   16 
 
  include/uapi/linux/videodev2.h |6 ++
  2 files changed, 22 insertions(+)

 diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml 
 b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 index 5c70b61..0aec831 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
 @@ -155,6 +155,22 @@
 /entry
   /row
   row
 +   entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
 +   entry5/entry
 +   entry
 + paraThis event is triggered when a resolution or format change
 +  is detected during runtime by the video device. It can be a
 +  runtime resolution change triggered by a video decoder or the
 +  format change happening on an HDMI connector. Application may
 +  need to reinitialize buffers before proceeding further./para
 +
 +  paraThis event has a v4l2-event-source-change; 
 associated
 + with it. This has significance only for v4l2 subdevs where the
 + structfieldpad_num/structfield field will be updated with
 + the pad number on which the event is triggered./para
 +   /entry
 + /row
 + row
 entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
 entry0x0800/entry
 entryBase event number for driver-private events./entry
 diff --git a/include/uapi/linux/videodev2.h 
 b/include/uapi/linux/videodev2.h
 index 6ae7bbe..12e0614 100644
 --- a/include/uapi/linux/videodev2.h
 +++ b/include/uapi/linux/videodev2.h
 @@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
  #define V4L2_EVENT_EOS 2
  #define V4L2_EVENT_CTRL3
  #define V4L2_EVENT_FRAME_SYNC  4
 +#define V4L2_EVENT_SOURCE_CHANGE   5
  #define V4L2_EVENT_PRIVATE_START   0x0800

  /* Payload for V4L2_EVENT_VSYNC */
 @@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
 __u32 frame_sequence;
  };

 +struct v4l2_event_source_change {
 +   __u32 pad_num;
 +};
 +
  struct v4l2_event {
 __u32   type;
 union {
 struct v4l2_event_vsync vsync;
 struct v4l2_event_ctrl  ctrl;
 struct v4l2_event_frame_syncframe_sync;
 +   struct v4l2_event_source_change source_change;
 __u8data[64];
 } u;
 __u32   pending;


 This needs to be done differently. The problem is that you really have 
 multiple
 events that you want to subscribe to: one for each pad (or input: see the 
 way
 VIDIOC_G/S_EDID maps pad to an input or output index when used with a 
 video node,
 we have to support that for this event as well).

 What you want to do is similar to what is done for control events: there 
 you can
 subscribe for a specific control and get notified when that control 
 changes.

 The way that works in the event code is that the 'id' field in the 
 v4l2_event
 struct contains that control ID, or, in this case, the pad/input/output 
 index.


 As I am new to v4l2-events itself, I might have some noob questions.
 I understood filling pad index into id field. But for video nodes,
 the application is supposed to put v4l2_buf_type in the id field?

 No, a capture video node can have multiple inputs (those are enumerated with
 VIDIOC_ENUMINPUTS), and each input can generate a SOURCE_CHANGE event, even 
 if it
 is not the currently active input. Hence the need of setting id to the input
 index. v4l2_buf_type makes no sense here.

 
 Ok. But in a simple m2m device like mfc, the userspace has to subscribe to
 the event say on the CAPTURE plane where buffers has to be re-allocated on
 resolution change. So in such a case, what should be put in id field?

M2M devices will only have one input and one output, so the ID will be 0.

Regards,

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

Re: [RFC v3 PATCH v6 11/16] ARM: dts: s6e3fa0: add DT bindings

[Andrzej Hajda]

On 04/27/2014 03:50 AM, YoungJun Cho wrote:
 This patch adds DT bindings for s6e3fa0 panel.
 The bindings describes panel resources, display timings and cpu mode timings.
 
 Changelog v2:
 - Adds unit address (commented by Sachin Kamat)
 Changelog v3:
 - Removes optional delay, size properties (commented by Laurent Pinchart)
 - Adds OLED detection, TE gpio properties
 Changelog v4:
 - Moves CPU timings relevant properties from FIMD DT
   (commeted by Laurent Pinchart, Andrzej Hajda)
 Changelog v5:
 - Fixes gpio property names (commented by Andrzej Hajda)
 Changelog v6:
 - Renames CPU timings to CPU mode timings
 - Modifies CPU mode timings internal properties relevant things
   (commeted by Laurent Pinchart, Andrzej Hajda)
 
 Signed-off-by: YoungJun Cho yj44@samsung.com
 Acked-by: Inki Dae inki@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   68 
 
  1 file changed, 68 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
 
 diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt 
 b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
 new file mode 100644
 index 000..9f06645
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
 @@ -0,0 +1,68 @@
 +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
 +
 +Required properties:
 +  - compatible: samsung,s6e3fa0
 +  - reg: the virtual channel number of a DSI peripheral
 +  - vdd3-supply: core voltage supply
 +  - vci-supply: voltage supply for analog circuits
 +  - reset-gpios: a GPIO spec for the reset pin
 +  - det-gpios: a GPIO spec for the OLED detection pin
 +  - te-gpios: a GPIO spec for the TE pin
 +  - display-timings: timings for the connected panel as described by [1]

This still bothers me, it forces users to provide bunch of fake
properties (four porches, two syncs and clock-frequency) just because we
need to pass somehow pixel width and height. And do we really need pixel
dimension to be passed via DT? I guess it could be:
- hardcoded into the driver,
- derived from the panel id,
- maybe read from the panel, this is the best option I guess but I am
not sure if panel provides an API for this.

Regards
Andrzej


 +  - cpu-mode-timings: CPU interface timings for the connected panel,
 +  and it contains following properties.
 +Required properties:
 +  - wr-active: clock cycles for the active period of CS enable in CPU
 +  interface.
 +Optional properties:
 +  - cs-setup: clock cycles for the active period of address signal
 +  enable until chip select is enable in CPU interface.
 +  If not specified, the default value(0) will be used.
 +  - wr-setup: clock cycles for the active period of CS signal enable
 +  until write signal is enable in CPU interface.
 +  If not specified, the default value(0) will be used.
 +  - wr-hold: clock cycles for the active period of CS disable until
 +  write signal is disable in CPU interface.
 +  If not specified, the default value(0) will be used.
 +
 +Optional properties:
 +
 +The device node can contain one 'port' child node with one child 'endpoint'
 +node, according to the bindings defined in [2]. This node should describe
 +panel's video bus.
 +
 +[1]: Documentation/devicetree/bindings/video/display-timing.txt
 +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
 +
 +Example:
 +
 + panel@0 {
 + compatible = samsung,s6e3fa0;
 + reg = 0;
 + vdd3-supply = vcclcd_reg;
 + vci-supply = vlcd_reg;
 + reset-gpios = gpy7 4 0;
 + det-gpios = gpg0 6 0;
 + te-gpios = gpd1 7 0;
 +
 + display-timings {
 + timing0: timing-0 {
 + clock-frequency = 0;
 + hactive = 1080;
 + vactive = 1920;
 + hfront-porch = 2;
 + hback-porch = 2;
 + hsync-len = 1;
 + vfront-porch = 1;
 + vback-porch = 4;
 + vsync-len = 1;
 + };
 + };
 +
 + cpu-mode-timings {
 + cs-setup = 0;
 + wr-setup = 0;
 + wr-active = 1;
 + wr-hold = 0;
 + };
 + };
 

--
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/7] ARM: EXYNOS: cpuidle: fix AFTR mode on boards with secure firmware enabled

[Bartlomiej Zolnierkiewicz]

Hi,

This patch series fixes support for AFTR idle mode on boards with
secure firmware enabled (it also includes fix for register setup on
EXYNOS4x12 SoCs).  It has been tested on Trats2 target but should
also work on (EXYNOS4412 based) Insignal Origen board.

This patchset depends on [PATCH V5 00/20] ARM: exynos: cpuidle:
Move the driver to drivers/cpuidle patch series from Daniel Lezcano
(http://www.spinics.net/lists/linux-samsung-soc/msg28494.html;).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics


Bartlomiej Zolnierkiewicz (5):
  ARM: EXYNOS: add AFTR mode support to firmware do_idle method
  ARM: EXYNOS: PM: replace EXYNOS_BOOT_VECTOR_* macros by static inlines
  ARM: EXYNOS: PM: use c15resume firmware method if secure firmware is
enabled
  ARM: EXYNOS: PM: fix register setup on EXYNOS4x12 for AFTR mode code
  ARM: EXYNOS: cpuidle: add secure firmware support to AFTR mode code

Kyungmin Park (1):
  arm: firmware: Check firmware is running or not

Tomasz Figa (1):
  ARM: EXYNOS: add support for firmware-assisted c15resume

 arch/arm/common/firmware.c   |  5 +
 arch/arm/include/asm/firmware.h  | 14 +-
 arch/arm/mach-exynos/firmware.c  | 18 --
 arch/arm/mach-exynos/pm.c| 40 
 drivers/cpuidle/cpuidle-exynos.c |  7 ++-
 5 files changed, 72 insertions(+), 12 deletions(-)

-- 
1.8.2.3

--
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/7] arm: firmware: Check firmware is running or not

[Bartlomiej Zolnierkiewicz]

From: Kyungmin Park kyungmin.p...@samsung.com

To support multi-platform, it needs to know it's running under secure
OS or not.  Sometimes it needs to access physical address by SMC calls.

e.g.,
if (firmware_run()) {
addr = physical address;
} else {
addr = virtual address;
}

call_firmware_ops(read_address, addr, value);

Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 arch/arm/common/firmware.c  | 5 +
 arch/arm/include/asm/firmware.h | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/common/firmware.c b/arch/arm/common/firmware.c
index 27ddccb..e9d9ee5 100644
--- a/arch/arm/common/firmware.c
+++ b/arch/arm/common/firmware.c
@@ -16,3 +16,8 @@
 static const struct firmware_ops default_firmware_ops;
 
 const struct firmware_ops *firmware_ops = default_firmware_ops;
+
+int firmware_run(void)
+{
+   return firmware_ops != default_firmware_ops;
+}
diff --git a/arch/arm/include/asm/firmware.h b/arch/arm/include/asm/firmware.h
index 2c9f10d..c72ec47 100644
--- a/arch/arm/include/asm/firmware.h
+++ b/arch/arm/include/asm/firmware.h
@@ -46,6 +46,9 @@ struct firmware_ops {
 /* Global pointer for current firmware_ops structure, can't be NULL. */
 extern const struct firmware_ops *firmware_ops;
 
+/* Check firmware is running */
+extern int firmware_run(void);
+
 /*
  * call_firmware_op(op, ...)
  *
-- 
1.8.2.3

--
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 5/7] ARM: EXYNOS: PM: use c15resume firmware method if secure firmware is enabled

[Bartlomiej Zolnierkiewicz]

Use c15resume firmware method instead of accessing the registers
directly in exynos_cpu_restore_register() if secure firmware is
enabled.  This affects both PM resume method and cpuidle AFTR mode.

This patch shouldn't cause any functionality changes on boards that
don't use secure firmware.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 arch/arm/mach-exynos/pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 1679c51..18f6bf8 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -26,6 +26,7 @@
 #include asm/hardware/cache-l2x0.h
 #include asm/smp_scu.h
 #include asm/suspend.h
+#include asm/firmware.h
 
 #include plat/cpu.h
 #include plat/pm-common.h
@@ -167,6 +168,9 @@ static void exynos_cpu_restore_register(void)
 {
unsigned long tmp;
 
+   if (call_firmware_op(c15resume, save_arm_register) == 0)
+   return;
+
/* Restore Power control register */
tmp = save_arm_register[0];
 
-- 
1.8.2.3

--
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 4/7] ARM: EXYNOS: PM: replace EXYNOS_BOOT_VECTOR_* macros by static inlines

[Bartlomiej Zolnierkiewicz]

Replace EXYNOS_BOOT_VECTOR_ADDR and EXYNOS_BOOT_VECTOR_FLAG macros
by exynos_boot_vector_addr() and exynos_boot_vector_flag() static
inlines.

This patch shouldn't cause any functionality changes.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 arch/arm/mach-exynos/pm.c | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index b380d48..1679c51 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -101,12 +101,23 @@ static int exynos_irq_set_wake(struct irq_data *data, 
unsigned int state)
return -ENOENT;
 }
 
-#define EXYNOS_BOOT_VECTOR_ADDR(samsung_rev() == EXYNOS4210_REV_1_1 ? \
-   S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
-   (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
-#define EXYNOS_BOOT_VECTOR_FLAG(samsung_rev() == EXYNOS4210_REV_1_1 ? \
-   S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
-   (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
+static inline void __iomem *exynos_boot_vector_addr(void)
+{
+   if (samsung_rev() == EXYNOS4210_REV_1_1)
+   return S5P_INFORM7;
+   else if (samsung_rev() == EXYNOS4210_REV_1_0)
+   return S5P_VA_SYSRAM + 0x24;
+   return S5P_INFORM0;
+}
+
+static inline void __iomem *exynos_boot_vector_flag(void)
+{
+   if (samsung_rev() == EXYNOS4210_REV_1_1)
+   return S5P_INFORM6;
+   else if (samsung_rev() == EXYNOS4210_REV_1_0)
+   return S5P_VA_SYSRAM + 0x20;
+   return S5P_INFORM1;
+}
 
 #define S5P_CHECK_AFTR  0xFCBA0D10
 #define S5P_CHECK_SLEEP 0x0BAD
@@ -119,8 +130,9 @@ static void exynos_set_wakeupmask(long mask)
 
 static void exynos_cpu_set_boot_vector(long flags)
 {
-   __raw_writel(virt_to_phys(exynos_cpu_resume), EXYNOS_BOOT_VECTOR_ADDR);
-   __raw_writel(flags, EXYNOS_BOOT_VECTOR_FLAG);
+   __raw_writel(virt_to_phys(exynos_cpu_resume),
+exynos_boot_vector_addr());
+   __raw_writel(flags, exynos_boot_vector_flag());
 }
 
 void exynos_enter_aftr(void)
-- 
1.8.2.3

--
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 6/7] ARM: EXYNOS: PM: fix register setup on EXYNOS4x12 for AFTR mode code

[Bartlomiej Zolnierkiewicz]

Add S5P_CENTRAL_SEQ_OPTION register setup for EXYNOS4x12 to AFTR
mode code.  Without this setup AFTR mode doesn't show any benefit
over WFI one.  When this setup is applied AFTR mode reduces power
consumption by ~12% (as measured on Trats2 board).

This change is a preparation for adding secure firmware support to
EXYNOS cpuidle driver.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 arch/arm/mach-exynos/pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 18f6bf8..3922968 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -391,6 +391,10 @@ static int exynos_cpu_pm_notifier(struct notifier_block 
*self,
case CPU_PM_ENTER:
if (cpu == 0) {
exynos_pm_central_suspend();
+   if (soc_is_exynos4212() || soc_is_exynos4412())
+   __raw_writel(S5P_USE_STANDBY_WFI0 |
+S5P_USE_STANDBY_WFE0,
+S5P_CENTRAL_SEQ_OPTION);
exynos_cpu_save_register();
}
break;
-- 
1.8.2.3

--
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/7] ARM: EXYNOS: add support for firmware-assisted c15resume

[Bartlomiej Zolnierkiewicz]

From: Tomasz Figa t.f...@samsung.com

This change is a preparation for adding secure firmware support to
EXYNOS cpuidle driver.

This patch shouldn't cause any functionality changes.

Signed-off-by: Tomasz Figa t.f...@samsung.com
[bzolnier: splitted out from bigger patch]
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 arch/arm/include/asm/firmware.h | 4 
 arch/arm/mach-exynos/firmware.c | 8 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/include/asm/firmware.h b/arch/arm/include/asm/firmware.h
index c72ec47..70883c7 100644
--- a/arch/arm/include/asm/firmware.h
+++ b/arch/arm/include/asm/firmware.h
@@ -41,6 +41,10 @@ struct firmware_ops {
 * Initializes L2 cache
 */
int (*l2x0_init)(void);
+   /*
+* Restores coprocessor 15 registers
+*/
+   int (*c15resume)(u32 *regs);
 };
 
 /* Global pointer for current firmware_ops structure, can't be NULL. */
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..581c7bf 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -40,10 +40,18 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
boot_addr)
return 0;
 }
 
+static int exynos_c15resume(u32 *regs)
+{
+   exynos_smc(SMC_CMD_C15RESUME, regs[0], regs[1], 0);
+
+   return 0;
+}
+
 static const struct firmware_ops exynos_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr  = exynos_set_cpu_boot_addr,
.cpu_boot   = exynos_cpu_boot,
+   .c15resume  = exynos_c15resume,
 };
 
 void __init exynos_firmware_init(void)
-- 
1.8.2.3

--
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 7/7] ARM: EXYNOS: cpuidle: add secure firmware support to AFTR mode code

[Bartlomiej Zolnierkiewicz]

* Use do_idle firmware method instead of cpu_do_idle() on boards
  with secure firmware enabled.

* Use S5P_VA_SYSRAM_NS + 0x24 address for exynos_boot_vector_addr()
  and S5P_VA_SYSRAM_NS + 0x20 one for exynos_boot_vector_flag() on
  boards with secure firmware enabled.

This patch fixes hang on an attempt to enter AFTR mode for TRATS2
board (which uses EXYNOS4412 SoC with secure firmware enabled).

This patch shouldn't cause any functionality changes on boards that
don't use secure firmware.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 arch/arm/mach-exynos/pm.c| 8 ++--
 drivers/cpuidle/cpuidle-exynos.c | 7 ++-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 3922968..ba4cd05 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -104,7 +104,9 @@ static int exynos_irq_set_wake(struct irq_data *data, 
unsigned int state)
 
 static inline void __iomem *exynos_boot_vector_addr(void)
 {
-   if (samsung_rev() == EXYNOS4210_REV_1_1)
+   if (firmware_run())
+   return S5P_VA_SYSRAM_NS + 0x24;
+   else if (samsung_rev() == EXYNOS4210_REV_1_1)
return S5P_INFORM7;
else if (samsung_rev() == EXYNOS4210_REV_1_0)
return S5P_VA_SYSRAM + 0x24;
@@ -113,7 +115,9 @@ static inline void __iomem *exynos_boot_vector_addr(void)
 
 static inline void __iomem *exynos_boot_vector_flag(void)
 {
-   if (samsung_rev() == EXYNOS4210_REV_1_1)
+   if (firmware_run())
+   return S5P_VA_SYSRAM_NS + 0x20;
+   else if (samsung_rev() == EXYNOS4210_REV_1_1)
return S5P_INFORM6;
else if (samsung_rev() == EXYNOS4210_REV_1_0)
return S5P_VA_SYSRAM + 0x20;
diff --git a/drivers/cpuidle/cpuidle-exynos.c b/drivers/cpuidle/cpuidle-exynos.c
index 7c01512..f90a4a0 100644
--- a/drivers/cpuidle/cpuidle-exynos.c
+++ b/drivers/cpuidle/cpuidle-exynos.c
@@ -17,13 +17,18 @@
 #include asm/proc-fns.h
 #include asm/suspend.h
 #include asm/cpuidle.h
+#include asm/firmware.h
 
 static void (*exynos_enter_aftr)(void);
 
 static int idle_finisher(unsigned long flags)
 {
exynos_enter_aftr();
-   cpu_do_idle();
+   if (firmware_run())
+   /* no need to check the return value on EXYNOS SoCs */
+   call_firmware_op(do_idle, FW_DO_IDLE_AFTR);
+   else
+   cpu_do_idle();
 
return 1;
 }
-- 
1.8.2.3

--
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/7] ARM: EXYNOS: add AFTR mode support to firmware do_idle method

[Bartlomiej Zolnierkiewicz]

On some platforms (i.e. EXYNOS ones) more than one idle mode is
available and we need to distinguish them in firmware do_idle method.

Add mode parameter to do_idle firmware method and AFTR mode support
to EXYNOS do_idle implementation.

This change is a preparation for adding secure firmware support to
EXYNOS cpuidle driver.

This patch shouldn't cause any functionality changes (please note
that do_idle firmware method is unused currently).

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 arch/arm/include/asm/firmware.h |  7 ++-
 arch/arm/mach-exynos/firmware.c | 10 --
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/firmware.h b/arch/arm/include/asm/firmware.h
index 70883c7..63989c3 100644
--- a/arch/arm/include/asm/firmware.h
+++ b/arch/arm/include/asm/firmware.h
@@ -28,7 +28,7 @@ struct firmware_ops {
/*
 * Enters CPU idle mode
 */
-   int (*do_idle)(void);
+   int (*do_idle)(int mode);
/*
 * Sets boot address of specified physical CPU
 */
@@ -47,6 +47,11 @@ struct firmware_ops {
int (*c15resume)(u32 *regs);
 };
 
+enum {
+   FW_DO_IDLE_NORMAL,
+   FW_DO_IDLE_AFTR,
+};
+
 /* Global pointer for current firmware_ops structure, can't be NULL. */
 extern const struct firmware_ops *firmware_ops;
 
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 581c7bf..71fe169 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -20,9 +20,15 @@
 
 #include smc.h
 
-static int exynos_do_idle(void)
+static int exynos_do_idle(int mode)
 {
-   exynos_smc(SMC_CMD_SLEEP, 0, 0, 0);
+   switch (mode) {
+   case FW_DO_IDLE_AFTR:
+   exynos_smc(SMC_CMD_CPU0AFTR, 0, 0, 0);
+   break;
+   case FW_DO_IDLE_NORMAL:
+   exynos_smc(SMC_CMD_SLEEP, 0, 0, 0);
+   }
return 0;
 }
 
-- 
1.8.2.3

--
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 00/10] thermal: exynos: various cleanups

[Bartlomiej Zolnierkiewicz]

Hi,

This patch series contains various cleanups for EXYNOS thermal
driver.  Overall it decreases driver's LOC by 13%.  It is based
on next-20140428 kernel.  It should not cause any functionality
changes.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics


Bartlomiej Zolnierkiewicz (10):
  thermal: exynos: remove unused struct exynos_tmu_registers entries
  thermal: exynos: remove unused defines
  thermal: exynos: remove dead code for HW_MODE calibration
  thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
calibration
  thermal: exynos: remove redundant pdata checks from
exynos_tmu_initialize()
  thermal: exynos: remove redundant threshold_code checks from
exynos_tmu_initialize()
  thermal: exynos: simplify temp_to_code() and code_to_temp()
  thermal: exynos: cache non_hw_trigger_levels in pdata
  thermal: exynos: remove redundant pdata checks from
exynos_tmu_control()
  thermal: exynos: remove identical values from exynos*_tmu_registers
structures

 drivers/thermal/samsung/exynos_thermal_common.h |   1 -
 drivers/thermal/samsung/exynos_tmu.c| 181 
 drivers/thermal/samsung/exynos_tmu.h|  86 +--
 drivers/thermal/samsung/exynos_tmu_data.c   |  40 +-
 drivers/thermal/samsung/exynos_tmu_data.h   |  32 +
 5 files changed, 37 insertions(+), 303 deletions(-)

-- 
1.8.2.3

--
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 01/10] thermal: exynos: remove unused struct exynos_tmu_registers entries

[Bartlomiej Zolnierkiewicz]

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.h  | 40 ---
 drivers/thermal/samsung/exynos_tmu_data.c |  2 --
 drivers/thermal/samsung/exynos_tmu_data.h |  1 -
 3 files changed, 43 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..80dc899 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -82,8 +82,6 @@ enum soc_type {
  * @triminfo_25_shift: shift bit of the 25 C trim value in triminfo_data reg.
  * @triminfo_85_shift: shift bit of the 85 C trim value in triminfo_data reg.
  * @triminfo_ctrl: trim info controller register.
- * @triminfo_reload_shift: shift of triminfo reload enable bit in triminfo_ctrl
-   reg.
  * @tmu_ctrl: TMU main controller register.
  * @test_mux_addr_shift: shift bits of test mux address.
  * @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl register.
@@ -98,27 +96,13 @@ enum soc_type {
register.
  * @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
register.
- * @therm_trip_tq_en_shift: shift bits of thermal trip enable by TQ pin in
-   tmu_ctrl register.
  * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
  * @tmu_status: register drescribing the TMU status.
  * @tmu_cur_temp: register containing the current temperature of the TMU.
- * @tmu_cur_temp_shift: shift bits of current temp value in tmu_cur_temp
-   register.
  * @threshold_temp: register containing the base threshold level.
  * @threshold_th0: Register containing first set of rising levels.
- * @threshold_th0_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th0_l1_shift: shift bits of level1 threshold temperature.
- * @threshold_th0_l2_shift: shift bits of level2 threshold temperature.
- * @threshold_th0_l3_shift: shift bits of level3 threshold temperature.
  * @threshold_th1: Register containing second set of rising levels.
- * @threshold_th1_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th1_l1_shift: shift bits of level1 threshold temperature.
- * @threshold_th1_l2_shift: shift bits of level2 threshold temperature.
- * @threshold_th1_l3_shift: shift bits of level3 threshold temperature.
  * @threshold_th2: Register containing third set of rising levels.
- * @threshold_th2_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th3: Register containing fourth set of rising levels.
  * @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
  * @tmu_inten: register containing the different threshold interrupt
enable bits.
@@ -131,15 +115,11 @@ enum soc_type {
  * @inten_rise2_shift: shift bits of rising 2 interrupt bits.
  * @inten_rise3_shift: shift bits of rising 3 interrupt bits.
  * @inten_fall0_shift: shift bits of falling 0 interrupt bits.
- * @inten_fall1_shift: shift bits of falling 1 interrupt bits.
- * @inten_fall2_shift: shift bits of falling 2 interrupt bits.
- * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
  * @tmu_intstat: Register containing the interrupt status values.
  * @tmu_intclear: Register for clearing the raised interrupt status.
  * @emul_con: TMU emulation controller register.
  * @emul_temp_shift: shift bits of emulation temperature.
  * @emul_time_shift: shift bits of emulation time.
- * @emul_time_mask: mask bits of emulation time.
  * @tmu_irqstatus: register to find which TMU generated interrupts.
  * @tmu_pmin: register to get/set the Pmin value.
  */
@@ -149,7 +129,6 @@ struct exynos_tmu_registers {
u32 triminfo_85_shift;
 
u32 triminfo_ctrl;
-   u32 triminfo_reload_shift;
 
u32 tmu_ctrl;
u32 test_mux_addr_shift;
@@ -162,32 +141,17 @@ struct exynos_tmu_registers {
u32 buf_slope_sel_mask;
u32 calib_mode_shift;
u32 calib_mode_mask;
-   u32 therm_trip_tq_en_shift;
u32 core_en_shift;
 
u32 tmu_status;
 
u32 tmu_cur_temp;
-   u32 tmu_cur_temp_shift;
 
u32 threshold_temp;
 
u32 threshold_th0;
-   u32 threshold_th0_l0_shift;
-   u32 threshold_th0_l1_shift;
-   u32 threshold_th0_l2_shift;
-   u32 threshold_th0_l3_shift;
-
u32 threshold_th1;
-   u32 threshold_th1_l0_shift;
-   u32 threshold_th1_l1_shift;
-   u32 threshold_th1_l2_shift;
-   u32 threshold_th1_l3_shift;
-
u32 threshold_th2;
-   u32 threshold_th2_l0_shift;
-
-   u32 threshold_th3;
u32 threshold_th3_l0_shift;
 
u32 tmu_inten;
@@ -200,9 +164,6 @@ struct exynos_tmu_registers {
u32 inten_rise2_shift;
u32 inten_rise3_shift;
u32 inten_fall0_shift;
-   u32 

[PATCH 02/10] thermal: exynos: remove unused defines

[Bartlomiej Zolnierkiewicz]

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu_data.h | 27 +--
 1 file changed, 1 insertion(+), 26 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
b/drivers/thermal/samsung/exynos_tmu_data.h
index 06c4345..d4eeddb 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -42,20 +42,8 @@
 /* Exynos4210 specific registers */
 #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP  0x44
 #define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50
-#define EXYNOS4210_TMU_REG_TRIG_LEVEL1 0x54
-#define EXYNOS4210_TMU_REG_TRIG_LEVEL2 0x58
-#define EXYNOS4210_TMU_REG_TRIG_LEVEL3 0x5C
-#define EXYNOS4210_TMU_REG_PAST_TEMP0  0x60
-#define EXYNOS4210_TMU_REG_PAST_TEMP1  0x64
-#define EXYNOS4210_TMU_REG_PAST_TEMP2  0x68
-#define EXYNOS4210_TMU_REG_PAST_TEMP3  0x6C
-
-#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK0x1
-#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK0x10
-#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK0x100
-#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK0x1000
+
 #define EXYNOS4210_TMU_TRIG_LEVEL_MASK 0x
-#define EXYNOS4210_TMU_INTCLEAR_VAL0x
 
 /* Exynos5250 and Exynos4412 specific registers */
 #define EXYNOS_TMU_TRIMINFO_CON0x14
@@ -69,8 +57,6 @@
 #define EXYNOS_TMU_RISE_INT_SHIFT  0
 #define EXYNOS_TMU_FALL_INT_MASK   0x111
 #define EXYNOS_TMU_FALL_INT_SHIFT  12
-#define EXYNOS_TMU_CLEAR_RISE_INT  0x111
-#define EXYNOS_TMU_CLEAR_FALL_INT  (0x111  12)
 #define EXYNOS_TMU_TRIP_MODE_SHIFT 13
 #define EXYNOS_TMU_TRIP_MODE_MASK  0x7
 #define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
@@ -82,8 +68,6 @@
 #define EXYNOS_TMU_INTEN_RISE2_SHIFT   8
 #define EXYNOS_TMU_INTEN_RISE3_SHIFT   12
 #define EXYNOS_TMU_INTEN_FALL0_SHIFT   16
-#define EXYNOS_TMU_INTEN_FALL1_SHIFT   20
-#define EXYNOS_TMU_INTEN_FALL2_SHIFT   24
 
 #define EXYNOS_EMUL_TIME   0x57F0
 #define EXYNOS_EMUL_TIME_MASK  0x
@@ -107,13 +91,11 @@
 #define EXYNOS5440_TMU_S0_7_TH00x110
 #define EXYNOS5440_TMU_S0_7_TH10x130
 #define EXYNOS5440_TMU_S0_7_TH20x150
-#define EXYNOS5440_TMU_S0_7_EVTEN  0x1F0
 #define EXYNOS5440_TMU_S0_7_IRQEN  0x210
 #define EXYNOS5440_TMU_S0_7_IRQ0x230
 /* exynos5440 common registers */
 #define EXYNOS5440_TMU_IRQ_STATUS  0x000
 #define EXYNOS5440_TMU_PMIN0x004
-#define EXYNOS5440_TMU_TEMP0x008
 
 #define EXYNOS5440_TMU_RISE_INT_MASK   0xf
 #define EXYNOS5440_TMU_RISE_INT_SHIFT  0
@@ -124,13 +106,6 @@
 #define EXYNOS5440_TMU_INTEN_RISE2_SHIFT   2
 #define EXYNOS5440_TMU_INTEN_RISE3_SHIFT   3
 #define EXYNOS5440_TMU_INTEN_FALL0_SHIFT   4
-#define EXYNOS5440_TMU_INTEN_FALL1_SHIFT   5
-#define EXYNOS5440_TMU_INTEN_FALL2_SHIFT   6
-#define EXYNOS5440_TMU_INTEN_FALL3_SHIFT   7
-#define EXYNOS5440_TMU_TH_RISE0_SHIFT  0
-#define EXYNOS5440_TMU_TH_RISE1_SHIFT  8
-#define EXYNOS5440_TMU_TH_RISE2_SHIFT  16
-#define EXYNOS5440_TMU_TH_RISE3_SHIFT  24
 #define EXYNOS5440_TMU_TH_RISE4_SHIFT  24
 #define EXYNOS5440_EFUSE_SWAP_OFFSET   8
 
-- 
1.8.2.3

--
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 03/10] thermal: exynos: remove dead code for HW_MODE calibration

[Bartlomiej Zolnierkiewicz]

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c  | 33 +--
 drivers/thermal/samsung/exynos_tmu.h  | 13 
 drivers/thermal/samsung/exynos_tmu_data.c |  3 ---
 drivers/thermal/samsung/exynos_tmu_data.h |  2 --
 4 files changed, 1 insertion(+), 50 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 0d96a51..9f2a5ee 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -76,9 +76,6 @@ static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp_code;
 
-   if (pdata-cal_mode == HW_MODE)
-   return temp;
-
if (data-soc == SOC_ARCH_EXYNOS4210)
/* temp should range between 25 and 125 */
if (temp  25 || temp  125) {
@@ -113,9 +110,6 @@ static int code_to_temp(struct exynos_tmu_data *data, u8 
temp_code)
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp;
 
-   if (pdata-cal_mode == HW_MODE)
-   return temp_code;
-
if (data-soc == SOC_ARCH_EXYNOS4210)
/* temp_code should range between 75 and 175 */
if (temp_code  75 || temp_code  175) {
@@ -164,9 +158,6 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
__raw_writel(1, data-base + reg-triminfo_ctrl);
 
-   if (pdata-cal_mode == HW_MODE)
-   goto skip_calib_data;
-
/* Save trimming info in order to perform calibration */
if (data-soc == SOC_ARCH_EXYNOS5440) {
/*
@@ -202,7 +193,6 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
(pdata-efuse_value  reg-triminfo_85_shift) 
EXYNOS_TMU_TEMP_MASK;
 
-skip_calib_data:
if (pdata-max_trigger_level  MAX_THRESHOLD_LEVS) {
dev_err(pdev-dev, Invalid max trigger level\n);
ret = -EINVAL;
@@ -311,7 +301,7 @@ static void exynos_tmu_control(struct platform_device 
*pdev, bool on)
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
struct exynos_tmu_platform_data *pdata = data-pdata;
const struct exynos_tmu_registers *reg = pdata-registers;
-   unsigned int con, interrupt_en, cal_val;
+   unsigned int con, interrupt_en;
 
mutex_lock(data-lock);
clk_enable(data-clk);
@@ -337,27 +327,6 @@ static void exynos_tmu_control(struct platform_device 
*pdev, bool on)
con |= (pdata-noise_cancel_mode  reg-therm_trip_mode_shift);
}
 
-   if (pdata-cal_mode == HW_MODE) {
-   con = ~(reg-calib_mode_mask  reg-calib_mode_shift);
-   cal_val = 0;
-   switch (pdata-cal_type) {
-   case TYPE_TWO_POINT_TRIMMING:
-   cal_val = 3;
-   break;
-   case TYPE_ONE_POINT_TRIMMING_85:
-   cal_val = 2;
-   break;
-   case TYPE_ONE_POINT_TRIMMING_25:
-   cal_val = 1;
-   break;
-   case TYPE_NONE:
-   break;
-   default:
-   dev_err(pdev-dev, Invalid calibration type, using 
none\n);
-   }
-   con |= cal_val  reg-calib_mode_shift;
-   }
-
if (on) {
con |= (1  reg-core_en_shift);
interrupt_en =
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 80dc899..e417af8 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -34,11 +34,6 @@ enum calibration_type {
TYPE_NONE,
 };
 
-enum calibration_mode {
-   SW_MODE,
-   HW_MODE,
-};
-
 enum soc_type {
SOC_ARCH_EXYNOS4210 = 1,
SOC_ARCH_EXYNOS4412,
@@ -92,10 +87,6 @@ enum soc_type {
  * @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
register.
  * @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl register.
- * @calib_mode_shift: shift bits of calibration mode value in tmu_ctrl
-   register.
- * @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
-   register.
  * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
  * @tmu_status: register drescribing the TMU status.
  * @tmu_cur_temp: register containing the current temperature of the TMU.
@@ -139,8 +130,6 @@ struct exynos_tmu_registers {
u32 therm_trip_en_shift;
u32 buf_slope_sel_shift;
u32 buf_slope_sel_mask;
-   u32 calib_mode_shift;
-   u32 calib_mode_mask;
u32 core_en_shift;
 
u32 tmu_status;

[PATCH 04/10] thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration

[Bartlomiej Zolnierkiewicz]

Only TYPE_ONE_POINT_TRIMMING calibration is used so remove
the dead code for TYPE_TWO_POINT_TRIMMING calibration.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c  | 55 ++-
 drivers/thermal/samsung/exynos_tmu.h  | 20 +--
 drivers/thermal/samsung/exynos_tmu_data.c | 17 +-
 drivers/thermal/samsung/exynos_tmu_data.h |  2 --
 4 files changed, 12 insertions(+), 82 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 9f2a5ee..903566f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -47,8 +47,7 @@
  * @irq_work: pointer to the irq work structure.
  * @lock: lock to implement synchronization.
  * @clk: pointer to the clock structure.
- * @temp_error1: fused value of the first point trim.
- * @temp_error2: fused value of the second point trim.
+ * @temp_error: fused value of the first point trim.
  * @regulator: pointer to the TMU regulator structure.
  * @reg_conf: pointer to structure to register with core thermal.
  */
@@ -62,14 +61,13 @@ struct exynos_tmu_data {
struct work_struct irq_work;
struct mutex lock;
struct clk *clk;
-   u8 temp_error1, temp_error2;
+   u8 temp_error;
struct regulator *regulator;
struct thermal_sensor_conf *reg_conf;
 };
 
 /*
  * TMU treats temperature as a mapped temperature code.
- * The temperature is converted differently depending on the calibration type.
  */
 static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
 {
@@ -83,20 +81,7 @@ static int temp_to_code(struct exynos_tmu_data *data, u8 
temp)
goto out;
}
 
-   switch (pdata-cal_type) {
-   case TYPE_TWO_POINT_TRIMMING:
-   temp_code = (temp - pdata-first_point_trim) *
-   (data-temp_error2 - data-temp_error1) /
-   (pdata-second_point_trim - pdata-first_point_trim) +
-   data-temp_error1;
-   break;
-   case TYPE_ONE_POINT_TRIMMING:
-   temp_code = temp + data-temp_error1 - pdata-first_point_trim;
-   break;
-   default:
-   temp_code = temp + pdata-default_temp_offset;
-   break;
-   }
+   temp_code = temp + data-temp_error - pdata-first_point_trim;
 out:
return temp_code;
 }
@@ -117,20 +102,7 @@ static int code_to_temp(struct exynos_tmu_data *data, u8 
temp_code)
goto out;
}
 
-   switch (pdata-cal_type) {
-   case TYPE_TWO_POINT_TRIMMING:
-   temp = (temp_code - data-temp_error1) *
-   (pdata-second_point_trim - pdata-first_point_trim) /
-   (data-temp_error2 - data-temp_error1) +
-   pdata-first_point_trim;
-   break;
-   case TYPE_ONE_POINT_TRIMMING:
-   temp = temp_code - data-temp_error1 + pdata-first_point_trim;
-   break;
-   default:
-   temp = temp_code - pdata-default_temp_offset;
-   break;
-   }
+   temp = temp_code - data-temp_error + pdata-first_point_trim;
 out:
return temp;
 }
@@ -179,19 +151,12 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
} else {
trim_info = readl(data-base + reg-triminfo_data);
}
-   data-temp_error1 = trim_info  EXYNOS_TMU_TEMP_MASK;
-   data-temp_error2 = ((trim_info  reg-triminfo_85_shift) 
-   EXYNOS_TMU_TEMP_MASK);
-
-   if (!data-temp_error1 ||
-   (pdata-min_efuse_value  data-temp_error1) ||
-   (data-temp_error1  pdata-max_efuse_value))
-   data-temp_error1 = pdata-efuse_value  EXYNOS_TMU_TEMP_MASK;
-
-   if (!data-temp_error2)
-   data-temp_error2 =
-   (pdata-efuse_value  reg-triminfo_85_shift) 
-   EXYNOS_TMU_TEMP_MASK;
+   data-temp_error = trim_info  EXYNOS_TMU_TEMP_MASK;
+
+   if (!data-temp_error ||
+   pdata-min_efuse_value  data-temp_error ||
+   data-temp_error  pdata-max_efuse_value)
+   data-temp_error = pdata-efuse_value  EXYNOS_TMU_TEMP_MASK;
 
if (pdata-max_trigger_level  MAX_THRESHOLD_LEVS) {
dev_err(pdev-dev, Invalid max trigger level\n);
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index e417af8..186e39e 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -26,14 +26,6 @@
 
 #include exynos_thermal_common.h
 
-enum calibration_type {
-   TYPE_ONE_POINT_TRIMMING,
-   TYPE_ONE_POINT_TRIMMING_25,
-   TYPE_ONE_POINT_TRIMMING_85,
-   TYPE_TWO_POINT_TRIMMING,
-   TYPE_NONE,
-};
-
 enum 

[PATCH 06/10] thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize()

[Bartlomiej Zolnierkiewicz]

Remove runtime checks for negative return values of temp_to_code()
from exynos_tmu_initialize().  The current level temperature data
hardcoded in pdata will never cause a negative temp_to_code()
return values and for the new code potential mistakes should be
caught during development/review phases.

Theres should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 789d745..a415829 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -170,10 +170,6 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
-   if (threshold_code  0) {
-   ret = threshold_code;
-   goto out;
-   }
writeb(threshold_code,
data-base + reg-threshold_temp);
for (i = 0; i  trigger_levs; i++)
@@ -187,18 +183,12 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
i  trigger_levs  i  EXYNOS_MAX_TRIGGER_PER_REG; i++) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
-   if (threshold_code  0) {
-   ret = threshold_code;
-   goto out;
-   }
rising_threshold |= threshold_code  8 * i;
if (pdata-threshold_falling) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i] -
pdata-threshold_falling);
-   if (threshold_code  0)
-   falling_threshold |=
-   threshold_code  8 * i;
+   falling_threshold |= threshold_code  8 * i;
}
}
 
@@ -217,10 +207,6 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
(pdata-trigger_type[i] == HW_TRIP)) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
-   if (threshold_code  0) {
-   ret = threshold_code;
-   goto out;
-   }
if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
/* 1-4 level to be assigned in th0 reg */
rising_threshold |= threshold_code  8 * i;
-- 
1.8.2.3

--
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 05/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize()

[Bartlomiej Zolnierkiewicz]

Remove runtime checks for pdata sanity from exynos_tmu_initialize().
The current values hardcoded in pdata will never trigger the checks
and for the new code potential mistakes should be caught during
development/review phases.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_thermal_common.h |  1 -
 drivers/thermal/samsung/exynos_tmu.c| 13 -
 2 files changed, 14 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..cd44719 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -27,7 +27,6 @@
 #define SENSOR_NAME_LEN16
 #define MAX_TRIP_COUNT 8
 #define MAX_COOLING_DEVICE 4
-#define MAX_THRESHOLD_LEVS 5
 
 #define ACTIVE_INTERVAL 500
 #define IDLE_INTERVAL 1
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 903566f..789d745 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -158,23 +158,10 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
data-temp_error  pdata-max_efuse_value)
data-temp_error = pdata-efuse_value  EXYNOS_TMU_TEMP_MASK;
 
-   if (pdata-max_trigger_level  MAX_THRESHOLD_LEVS) {
-   dev_err(pdev-dev, Invalid max trigger level\n);
-   ret = -EINVAL;
-   goto out;
-   }
-
for (i = 0; i  pdata-max_trigger_level; i++) {
if (!pdata-trigger_levels[i])
continue;
 
-   if ((pdata-trigger_type[i] == HW_TRIP) 
-   (!pdata-trigger_levels[pdata-max_trigger_level - 1])) {
-   dev_err(pdev-dev, Invalid hw trigger level\n);
-   ret = -EINVAL;
-   goto out;
-   }
-
/* Count trigger levels except the HW trip*/
if (!(pdata-trigger_type[i] == HW_TRIP))
trigger_levs++;
-- 
1.8.2.3

--
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 07/10] thermal: exynos: simplify temp_to_code() and code_to_temp()

[Bartlomiej Zolnierkiewicz]

* Remove dead temp check from temp_to_code() (this function users
  in exynos_tmu_initialize() always pass correct temperatures and
  exynos_tmu_set_emulation() returns early for EXYNOS4210 because
  TMU_SUPPORT_EMULATION flag is not set on this SoC).

* Move temp_code check from code_to_temp() to exynos_tmu_read()
  (code_to_temp() only user).

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c | 38 +++-
 1 file changed, 11 insertions(+), 27 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index a415829..20379eb 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -71,19 +71,7 @@ struct exynos_tmu_data {
  */
 static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
 {
-   struct exynos_tmu_platform_data *pdata = data-pdata;
-   int temp_code;
-
-   if (data-soc == SOC_ARCH_EXYNOS4210)
-   /* temp should range between 25 and 125 */
-   if (temp  25 || temp  125) {
-   temp_code = -EINVAL;
-   goto out;
-   }
-
-   temp_code = temp + data-temp_error - pdata-first_point_trim;
-out:
-   return temp_code;
+   return temp + data-temp_error - data-pdata-first_point_trim;
 }
 
 /*
@@ -92,19 +80,7 @@ out:
  */
 static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
 {
-   struct exynos_tmu_platform_data *pdata = data-pdata;
-   int temp;
-
-   if (data-soc == SOC_ARCH_EXYNOS4210)
-   /* temp_code should range between 75 and 175 */
-   if (temp_code  75 || temp_code  175) {
-   temp = -ENODATA;
-   goto out;
-   }
-
-   temp = temp_code - data-temp_error + pdata-first_point_trim;
-out:
-   return temp;
+   return temp_code - data-temp_error + data-pdata-first_point_trim;
 }
 
 static int exynos_tmu_initialize(struct platform_device *pdev)
@@ -297,8 +273,16 @@ static int exynos_tmu_read(struct exynos_tmu_data *data)
clk_enable(data-clk);
 
temp_code = readb(data-base + reg-tmu_cur_temp);
-   temp = code_to_temp(data, temp_code);
 
+   if (data-soc == SOC_ARCH_EXYNOS4210)
+   /* temp_code should range between 75 and 175 */
+   if (temp_code  75 || temp_code  175) {
+   temp = -ENODATA;
+   goto out;
+   }
+
+   temp = code_to_temp(data, temp_code);
+out:
clk_disable(data-clk);
mutex_unlock(data-lock);
 
-- 
1.8.2.3

--
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 10/10] thermal: exynos: remove identical values from exynos*_tmu_registers structures

[Bartlomiej Zolnierkiewicz]

There is no need for abstracting configuration for registers that
are identical on all SoC types.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c  | 12 ++--
 drivers/thermal/samsung/exynos_tmu.h  | 11 ---
 drivers/thermal/samsung/exynos_tmu_data.c | 15 ---
 3 files changed, 6 insertions(+), 32 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 45d7c6f..d37e755 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -215,11 +215,11 @@ static void exynos_tmu_control(struct platform_device 
*pdev, bool on)
if (pdata-test_mux)
con |= (pdata-test_mux  reg-test_mux_addr_shift);
 
-   con = ~(reg-buf_vref_sel_mask  reg-buf_vref_sel_shift);
-   con |= pdata-reference_voltage  reg-buf_vref_sel_shift;
+   con = ~(EXYNOS_TMU_REF_VOLTAGE_MASK  EXYNOS_TMU_REF_VOLTAGE_SHIFT);
+   con |= pdata-reference_voltage  EXYNOS_TMU_REF_VOLTAGE_SHIFT;
 
-   con = ~(reg-buf_slope_sel_mask  reg-buf_slope_sel_shift);
-   con |= (pdata-gain  reg-buf_slope_sel_shift);
+   con = ~(EXYNOS_TMU_BUF_SLOPE_SEL_MASK  
EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT);
+   con |= (pdata-gain  EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT);
 
if (pdata-noise_cancel_mode) {
con = ~(reg-therm_trip_mode_mask 
@@ -228,7 +228,7 @@ static void exynos_tmu_control(struct platform_device 
*pdev, bool on)
}
 
if (on) {
-   con |= (1  reg-core_en_shift);
+   con |= (1  EXYNOS_TMU_CORE_EN_SHIFT);
interrupt_en =
pdata-trigger_enable[3]  reg-inten_rise3_shift |
pdata-trigger_enable[2]  reg-inten_rise2_shift |
@@ -238,7 +238,7 @@ static void exynos_tmu_control(struct platform_device 
*pdev, bool on)
interrupt_en |=
interrupt_en  reg-inten_fall0_shift;
} else {
-   con = ~(1  reg-core_en_shift);
+   con = ~(1  EXYNOS_TMU_CORE_EN_SHIFT);
interrupt_en = 0; /* Disable all interrupts */
}
writel(interrupt_en, data-base + reg-tmu_inten);
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 4845171..5c25a4b 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -69,15 +69,9 @@ enum soc_type {
  * @triminfo_ctrl: trim info controller register.
  * @tmu_ctrl: TMU main controller register.
  * @test_mux_addr_shift: shift bits of test mux address.
- * @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl register.
- * @buf_vref_sel_mask: mask bits of reference voltage in tmu_ctrl register.
  * @therm_trip_mode_shift: shift bits of tripping mode in tmu_ctrl register.
  * @therm_trip_mode_mask: mask bits of tripping mode in tmu_ctrl register.
  * @therm_trip_en_shift: shift bits of tripping enable in tmu_ctrl register.
- * @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
-   register.
- * @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl register.
- * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
  * @tmu_status: register drescribing the TMU status.
  * @tmu_cur_temp: register containing the current temperature of the TMU.
  * @threshold_temp: register containing the base threshold level.
@@ -111,14 +105,9 @@ struct exynos_tmu_registers {
 
u32 tmu_ctrl;
u32 test_mux_addr_shift;
-   u32 buf_vref_sel_shift;
-   u32 buf_vref_sel_mask;
u32 therm_trip_mode_shift;
u32 therm_trip_mode_mask;
u32 therm_trip_en_shift;
-   u32 buf_slope_sel_shift;
-   u32 buf_slope_sel_mask;
-   u32 core_en_shift;
 
u32 tmu_status;
 
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
index ef7f186..32530dc 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -28,11 +28,6 @@
 static const struct exynos_tmu_registers exynos4210_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
-   .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
-   .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
-   .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
-   .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
-   .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
.tmu_status = EXYNOS_TMU_REG_STATUS,
.tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
.threshold_temp = EXYNOS4210_TMU_REG_THRESHOLD_TEMP,
@@ -92,14 +87,9 @@ static const struct exynos_tmu_registers 
exynos4412_tmu_registers = {
.triminfo_ctrl = 

[PATCH 09/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_control()

[Bartlomiej Zolnierkiewicz]

pdata-reference_voltage and pdata-gain are always defined
to non-zero values so remove the redundant checks from
exynos_tmu_control().

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index a8d9524..45d7c6f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -215,15 +215,11 @@ static void exynos_tmu_control(struct platform_device 
*pdev, bool on)
if (pdata-test_mux)
con |= (pdata-test_mux  reg-test_mux_addr_shift);
 
-   if (pdata-reference_voltage) {
-   con = ~(reg-buf_vref_sel_mask  reg-buf_vref_sel_shift);
-   con |= pdata-reference_voltage  reg-buf_vref_sel_shift;
-   }
+   con = ~(reg-buf_vref_sel_mask  reg-buf_vref_sel_shift);
+   con |= pdata-reference_voltage  reg-buf_vref_sel_shift;
 
-   if (pdata-gain) {
-   con = ~(reg-buf_slope_sel_mask  reg-buf_slope_sel_shift);
-   con |= (pdata-gain  reg-buf_slope_sel_shift);
-   }
+   con = ~(reg-buf_slope_sel_mask  reg-buf_slope_sel_shift);
+   con |= (pdata-gain  reg-buf_slope_sel_shift);
 
if (pdata-noise_cancel_mode) {
con = ~(reg-therm_trip_mode_mask 
-- 
1.8.2.3

--
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 08/10] thermal: exynos: cache non_hw_trigger_levels in pdata

[Bartlomiej Zolnierkiewicz]

Cache number of non-hardware trigger levels in a new pdata field
(non_hw_trigger_levels) and convert code in exynos_tmu_initialize()
accordingly.

There should be no functional changes caused by this patch.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c  | 16 +++-
 drivers/thermal/samsung/exynos_tmu.h  |  2 ++
 drivers/thermal/samsung/exynos_tmu_data.c |  3 +++
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 20379eb..a8d9524 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -90,7 +90,7 @@ static int exynos_tmu_initialize(struct platform_device *pdev)
const struct exynos_tmu_registers *reg = pdata-registers;
unsigned int status, trim_info = 0, con;
unsigned int rising_threshold = 0, falling_threshold = 0;
-   int ret = 0, threshold_code, i, trigger_levs = 0;
+   int ret = 0, threshold_code, i;
 
mutex_lock(data-lock);
clk_enable(data-clk);
@@ -134,29 +134,19 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
data-temp_error  pdata-max_efuse_value)
data-temp_error = pdata-efuse_value  EXYNOS_TMU_TEMP_MASK;
 
-   for (i = 0; i  pdata-max_trigger_level; i++) {
-   if (!pdata-trigger_levels[i])
-   continue;
-
-   /* Count trigger levels except the HW trip*/
-   if (!(pdata-trigger_type[i] == HW_TRIP))
-   trigger_levs++;
-   }
-
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
writeb(threshold_code,
data-base + reg-threshold_temp);
-   for (i = 0; i  trigger_levs; i++)
+   for (i = 0; i  pdata-non_hw_trigger_levels; i++)
writeb(pdata-trigger_levels[i], data-base +
reg-threshold_th0 + i * sizeof(reg-threshold_th0));
 
writel(reg-inten_rise_mask, data-base + reg-tmu_intclear);
} else {
/* Write temperature code for rising and falling threshold */
-   for (i = 0;
-   i  trigger_levs  i  EXYNOS_MAX_TRIGGER_PER_REG; i++) {
+   for (i = 0; i  pdata-non_hw_trigger_levels; i++) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
rising_threshold |= threshold_code  8 * i;
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 186e39e..4845171 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -183,6 +183,7 @@ struct exynos_tmu_registers {
  * 1 = enable trigger_level[] interrupt,
  * 0 = disable trigger_level[] interrupt
  * @max_trigger_level: max trigger level supported by the TMU
+ * @non_hw_trigger_levels: number of defined non-hardware trigger levels
  * @gain: gain of amplifier in the positive-TC generator block
  * 0 = gain = 15
  * @reference_voltage: reference voltage of amplifier
@@ -213,6 +214,7 @@ struct exynos_tmu_platform_data {
enum trigger_type trigger_type[MAX_TRIP_COUNT];
bool trigger_enable[MAX_TRIP_COUNT];
u8 max_trigger_level;
+   u8 non_hw_trigger_levels;
u8 gain;
u8 reference_voltage;
u8 noise_cancel_mode;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
index c32d186..ef7f186 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -62,6 +62,7 @@ struct exynos_tmu_init_data const exynos4210_default_tmu_data 
= {
.trigger_type[1] = THROTTLE_ACTIVE,
.trigger_type[2] = SW_TRIP,
.max_trigger_level = 4,
+   .non_hw_trigger_levels = 3,
.gain = 15,
.reference_voltage = 7,
.min_efuse_value = 40,
@@ -135,6 +136,7 @@ static const struct exynos_tmu_registers 
exynos4412_tmu_registers = {
.trigger_type[2] = SW_TRIP, \
.trigger_type[3] = HW_TRIP, \
.max_trigger_level = 4, \
+   .non_hw_trigger_levels = 3, \
.gain = 8, \
.reference_voltage = 16, \
.noise_cancel_mode = 4, \
@@ -225,6 +227,7 @@ static const struct exynos_tmu_registers 
exynos5440_tmu_registers = {
.trigger_type[0] = SW_TRIP, \
.trigger_type[4] = HW_TRIP, \
.max_trigger_level = 5, \
+   .non_hw_trigger_levels = 1, \
.gain = 5, \
.reference_voltage = 16, \
.noise_cancel_mode = 4, \
-- 
1.8.2.3

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the 

Re: [RFC v3 PATCH v2 10/16] drm/exynos: dsi: add driver data to support Exynos5420

[Andrzej Hajda]

On 04/27/2014 03:50 AM, YoungJun Cho wrote:
 The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
 from the one in Exynos4 SoC.
 
 In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
 and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
 So this patch adds driver data to distinguish it.
 
 Changelog v2:
 - Moves exynos_dsi_enable_clocks() after exynos_dsi_reset()
   (commented by Andrzej Hajda)
 - Splits D-PHY control setting routines from PLL setting one
   (commented by Andrzej Hajda)
 
 Signed-off-by: YoungJun Cho yj44@samsung.com
 Acked-by: Inki Dae inki@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  154 
 ++-
  1 file changed, 132 insertions(+), 22 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
 index 4a918ec..c18dba3 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
 @@ -17,6 +17,7 @@
  
  #include linux/clk.h
  #include linux/irq.h
 +#include linux/of_device.h
  #include linux/phy/phy.h
  #include linux/regulator/consumer.h
  
 @@ -54,9 +55,12 @@
  
  /* FIFO memory AC characteristic register */
  #define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
 -#define DSIM_PLLTMR_REG  0x50/* PLL timer register */
  #define DSIM_PHYACCHR_REG0x54/* D-PHY AC characteristic register */
  #define DSIM_PHYACCHR1_REG   0x58/* D-PHY AC characteristic register1 */
 +#define DSIM_PHYCTRL_REG 0x5c
 +#define DSIM_PHYTIMING_REG   0x64
 +#define DSIM_PHYTIMING1_REG  0x68
 +#define DSIM_PHYTIMING2_REG  0x6c
  
  /* DSIM_STATUS */
  #define DSIM_STOP_STATE_DAT(x)   (((x)  0xf)  0)
 @@ -200,6 +204,21 @@
  #define DSIM_PLL_M(x)((x)  4)
  #define DSIM_PLL_S(x)((x)  1)
  
 +/* DSIM_PHYTIMING */
 +#define DSIM_PHYTIMING_LPX(x)((x)  8)
 +#define DSIM_PHYTIMING_HS_EXIT(x)((x)  0)
 +
 +/* DSIM_PHYTIMING1 */
 +#define DSIM_PHYTIMING1_CLK_PREPARE(x)   ((x)  24)
 +#define DSIM_PHYTIMING1_CLK_ZERO(x)  ((x)  16)
 +#define DSIM_PHYTIMING1_CLK_POST(x)  ((x)  8)
 +#define DSIM_PHYTIMING1_CLK_TRAIL(x) ((x)  0)
 +
 +/* DSIM_PHYTIMING2 */
 +#define DSIM_PHYTIMING2_HS_PREPARE(x)((x)  16)
 +#define DSIM_PHYTIMING2_HS_ZERO(x)   ((x)  8)
 +#define DSIM_PHYTIMING2_HS_TRAIL(x)  ((x)  0)
 +
  #define DSI_MAX_BUS_WIDTH4
  #define DSI_NUM_VIRTUAL_CHANNELS 4
  #define DSI_TX_FIFO_SIZE 2048
 @@ -233,6 +252,12 @@ struct exynos_dsi_transfer {
  #define DSIM_STATE_INITIALIZED   BIT(1)
  #define DSIM_STATE_CMD_LPM   BIT(2)
  
 +struct exynos_dsi_driver_data {
 + unsigned int plltmr_reg;
 +
 + unsigned int has_freqband:1;
 +};
 +
  struct exynos_dsi {
   struct mipi_dsi_host dsi_host;
   struct drm_connector connector;
 @@ -262,11 +287,39 @@ struct exynos_dsi {
  
   spinlock_t transfer_lock; /* protects transfer_list */
   struct list_head transfer_list;
 +
 + struct exynos_dsi_driver_data *driver_data;
  };
  
  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
  #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
  
 +static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
 + .plltmr_reg = 0x50,
 + .has_freqband = 1,
 +};
 +
 +static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
 + .plltmr_reg = 0x58,
 +};
 +
 +static struct of_device_id exynos_dsi_of_match[] = {
 + { .compatible = samsung,exynos4210-mipi-dsi,
 +   .data = exynos4_dsi_driver_data },
 + { .compatible = samsung,exynos5420-mipi-dsi,
 +   .data = exynos5_dsi_driver_data },
 + { }
 +};

I raise again issue of compatible string.
Since exynos5410 DSIM contains DSIM_VERSION register, it is better
to use this register instead of compatible string to distinguish
device versions. So as a compatible we should use the first exynos
chipset containing this field. AFAIK it is exynos5410.
So the only thing you should do is to change compatible string from
samsung,exynos5420-mipi-dsi to samsung,exynos5410-mipi-dsi.

 
 I posted RFC v3 without this try.
 
 Because there is no exynos5410 relevant DTS yet,
 and making exynos5410 DTS is out of scope for this RFC.


It is irrelevant.

Regards
Andrzej


 +
 +static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
 + struct platform_device *pdev)
 +{
 + const struct of_device_id *of_id =
 + of_match_device(exynos_dsi_of_match, pdev-dev);
 +
 + return (struct exynos_dsi_driver_data *)of_id-data;
 +}
 +
  static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
  {
   if (wait_for_completion_timeout(dsi-completed, msecs_to_jiffies(300)))
 @@ -340,14 +393,9 @@ static unsigned long 

[PATCH 1/2] ARM: dts: Enable USB 3503 hub on exynos5250-snow

[Vivek Gautam]

The exynos5250-snow has a SMSC USB3503 connected in
hardware only mode like a PHY. Enable support for it,
and add necessary 'reset-gpio' for it.

This is in correspondance to similar patch by Mark Brown
7c1b0ec ARM: dts: Enable USB hub on Arndale

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---

Based on 'for-next' branch of kgene's linux-samsung tree.

 arch/arm/boot/dts/exynos5250-pinctrl.dtsi |7 +++
 arch/arm/boot/dts/exynos5250-snow.dts |   14 ++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 9a49e68..bd8c8f1 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -706,6 +706,13 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+   usb_hub_reset: usb-hub-reset {
+   samsung,pins = gpe1-0;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
};
 
pinctrl@10d1 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..2e48f27 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -200,6 +200,20 @@
samsung,vbus-gpio = gpx1 1 0;
};
 
+   usb_hub_bus {
+   compatible = simple-bus;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   // SMSC USB3503 connected in hardware only mode as a PHY
+   usb_hub {
+   compatible = smsc,usb3503a;
+   reset-gpios = gpe1 0 1;
+   pinctrl-0 = usb_hub_reset;
+   pinctrl-names = default;
+   };
+   };
+
fixed-rate-clocks {
xxti {
compatible = samsung,clock-xxti;
-- 
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

[PATCH 2/2] ARM: dts: Enable USB 3503 hub on exynos5420-peach-pit

[Vivek Gautam]

The exynos5420-peach-pit has a SMSC USB3503 connected in
hardware only mode like a PHY. Enable support for it,
and add necessary 'reset-gpio' for it.

This is in correspondance to similar patch by Mark Brown
7c1b0ec ARM: dts: Enable USB hub on Arndale

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---

Based on 'for-next' branch of kgene's linux-samsung tree with
following patch:
[PATCH v4 2/2] ARM: dts: Add peach-pit board support
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29950.html

 arch/arm/boot/dts/exynos5420-peach-pit.dts |   14 ++
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 +++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index fae33dd..24c1e87 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -58,6 +58,20 @@
pinctrl-0 = pwm0_out;
pinctrl-names = default;
};
+
+   usb_hub_bus {
+   compatible = simple-bus;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   // SMSC USB3503 connected in hardware only mode as a PHY
+   usb_hub {
+   compatible = smsc,usb3503a;
+   reset-gpios = gpx2 4 1;
+   pinctrl-0 = usb_hub_reset;
+   pinctrl-names = default;
+   };
+   };
 };
 
 pinctrl_0 {
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index e62c8eb..8add143 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -66,6 +66,13 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+   usb_hub_reset: usb-hub-reset {
+   samsung,pins = gpx2-4;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
};
 
pinctrl@1341 {
-- 
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

[PATCH 1/2] PM / OPP: Remove cpufreq wrapper dependency on internal data organization

[Nishanth Menon]

CPUFREQ custom functions for OPP (Operating Performance Points)
currently exist inside the OPP library. These custom functions currently
depend on internal data structures to pick up OPP information to create
the cpufreq table.  For example, the cpufreq table is created precisely
in the same order of how OPP entries are stored inside the list implementation.

This kind of tight interdependency is purely artificial since the same
functionality can be achieved using the generic OPP functions
meant to do the same. This interdependency also limits the independent
modification of cpufreq and OPP library.

So use the generic dev_pm_opp_find_freq_ceil function that achieves the
table organization as we currently use.

As a result of this, we dont need to use the internal device_opp
structure anymore, and we hence we can switch over to rcu lock instead
of the mutex holding the internal list lock.

This breaking of dependency on internal data structure imposes no change
to usage of these.

NOTE: This change is a precursor to moving this cpufreq specific logic
out of the generic library into cpufreq.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: cpuf...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org

Signed-off-by: Nishanth Menon n...@ti.com
---
 drivers/base/power/opp.c |   55 +++---
 1 file changed, 28 insertions(+), 27 deletions(-)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 2553867..38b43bb 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -617,53 +617,54 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
  * the table if any of the mentioned functions have been invoked in the 
interim.
  *
  * Locking: The internal device_opp and opp structures are RCU protected.
- * To simplify the logic, we pretend we are updater and hold relevant mutex 
here
- * Callers should ensure that this function is *NOT* called under RCU 
protection
- * or in contexts where mutex locking cannot be used.
+ * Since we just use the regular accessor functions to access the internal data
+ * structures, we use RCU read lock inside this function. As a result, users of
+ * this function DONOT need to use explicit locks for invoking.
  */
 int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table)
 {
-   struct device_opp *dev_opp;
struct dev_pm_opp *opp;
-   struct cpufreq_frequency_table *freq_table;
-   int i = 0;
+   struct cpufreq_frequency_table *freq_table = NULL;
+   int i, max_opps, ret = 0;
+   unsigned long rate;
 
-   /* Pretend as if I am an updater */
-   mutex_lock(dev_opp_list_lock);
+   rcu_read_lock();
 
-   dev_opp = find_device_opp(dev);
-   if (IS_ERR(dev_opp)) {
-   int r = PTR_ERR(dev_opp);
-   mutex_unlock(dev_opp_list_lock);
-   dev_err(dev, %s: Device OPP not found (%d)\n, __func__, r);
-   return r;
+   max_opps = dev_pm_opp_get_opp_count(dev);
+   if (max_opps = 0) {
+   ret = max_opps ? max_opps : -ENODATA;
+   goto out;
}
 
-   freq_table = kzalloc(sizeof(struct cpufreq_frequency_table) *
-(dev_pm_opp_get_opp_count(dev) + 1), GFP_KERNEL);
+   freq_table = kzalloc(sizeof(*freq_table) * (max_opps + 1), GFP_KERNEL);
if (!freq_table) {
-   mutex_unlock(dev_opp_list_lock);
-   dev_warn(dev, %s: Unable to allocate frequency table\n,
-   __func__);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto out;
}
 
-   list_for_each_entry(opp, dev_opp-opp_list, node) {
-   if (opp-available) {
-   freq_table[i].driver_data = i;
-   freq_table[i].frequency = opp-rate / 1000;
-   i++;
+   for (i = 0, rate = 0; i  max_opps; i++, rate++) {
+   /* find next rate */
+   opp = dev_pm_opp_find_freq_ceil(dev, rate);
+   if (IS_ERR(opp)) {
+   ret = PTR_ERR(opp);
+   goto out;
}
+   freq_table[i].driver_data = i;
+   freq_table[i].frequency = rate / 1000;
}
-   mutex_unlock(dev_opp_list_lock);
 
freq_table[i].driver_data = i;
freq_table[i].frequency = CPUFREQ_TABLE_END;
 
*table = freq_table[0];
 
-   return 0;
+out:
+   rcu_read_unlock();
+   if (ret)
+   kfree(freq_table);
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a 

[PATCH 2/2] PM / OPP: Move cpufreq specific OPP functions out of generic OPP library

[Nishanth Menon]

CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.

Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.

Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: cpuf...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org

Signed-off-by: Nishanth Menon n...@ti.com
---
List of files impacted by this change detected by:
  # check if pm_opp.h header is needed anymore:
  git grep dev_pm_opp_init_cpufreq_table .|cut -d ':' -f1|sort|uniq|xargs
  grep dev_pm_opp |grep -v cpufreq
  # check if any file is missing cpufreq.h header is needed anymore:
 git grep dev_pm_opp_init_cpufreq_table .|cut -d ':' -f1|sort|uniq|xargs
 grep cpufreq.h

 Documentation/cpu-freq/core.txt |   29 +++
 Documentation/power/opp.txt |   40 ++
 drivers/base/power/opp.c|   92 
 drivers/cpufreq/Makefile|2 +
 drivers/cpufreq/cpufreq_opp.c   |  110 +++
 include/linux/cpufreq.h |   21 
 include/linux/pm_opp.h  |   20 ---
 7 files changed, 167 insertions(+), 147 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_opp.c

diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
index 0060d76..70933ea 100644
--- a/Documentation/cpu-freq/core.txt
+++ b/Documentation/cpu-freq/core.txt
@@ -20,6 +20,7 @@ Contents:
 -
 1.  CPUFreq core and interfaces
 2.  CPUFreq notifiers
+3.  CPUFreq Table Generation with Operating Performance Point (OPP)
 
 1. General Information
 ===
@@ -92,3 +93,31 @@ values:
 cpu- number of the affected CPU
 old- old frequency
 new- new frequency
+
+3. CPUFreq Table Generation with Operating Performance Point (OPP)
+==
+For details about OPP, see Documentation/power/opp.txt
+
+dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with
+   cpufreq_frequency_table_cpuinfo which is provided with the list of
+   frequencies that are available for operation. This function provides
+   a ready to use conversion routine to translate the OPP layer's internal
+   information about the available frequencies into a format readily
+   providable to cpufreq.
+
+   WARNING: Do not use this function in interrupt context.
+
+   Example:
+soc_pm_init()
+{
+   /* Do things */
+   r = dev_pm_opp_init_cpufreq_table(dev, freq_table);
+   if (!r)
+   cpufreq_frequency_table_cpuinfo(policy, freq_table);
+   /* Do other things */
+}
+
+   NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
+   addition to CONFIG_PM_OPP.
+
+dev_pm_opp_free_cpufreq_table - Free up the table allocated by 
dev_pm_opp_init_cpufreq_table
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index b8a907d..a9adad8 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -10,8 +10,7 @@ Contents
 3. OPP Search Functions
 4. OPP Availability Control Functions
 5. OPP Data Retrieval Functions
-6. Cpufreq Table Generation
-7. Data Structures
+6. Data Structures
 
 1. Introduction
 ===
@@ -72,7 +71,6 @@ operations until that OPP could be re-enabled if possible.
 OPP library facilitates this concept in it's implementation. The following
 operational functions operate only on available opps:
 opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, 
dev_pm_opp_get_opp_count
-and dev_pm_opp_init_cpufreq_table
 
 dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which 
can then
 be used for dev_pm_opp_enable/disable functions to make an opp available as 
required.
@@ -96,10 +94,9 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor},
 opp_get_{voltage, freq, opp_count} fall into this category.
 
 opp_{add,enable,disable} are updaters which use mutex and implement it's own
-RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and 
uses
-mutex to implment RCU updater strategy. These functions should *NOT* be called
-under RCU locks and other contexts that prevent blocking functions in RCU or
-mutex operations from working.
+RCU locking mechanisms. These functions should *NOT* be called under RCU locks
+and other contexts that prevent blocking functions in RCU or mutex operations
+from working.
 
 2. Initial OPP List Registration
 
@@ 

[PATCH 0/2] PM / OPP: move cpufreq specific helpers out of OPP layer

[Nishanth Menon]

CPUFreq usage of OPP should be independent of the ordering of type of
data storage inside OPP layer. The current operations can equally be
performed by generic operations.

[RFC]: https://patchwork.kernel.org/patch/4100811/

Series based on: v3.15-rc1

Nishanth Menon (2):
  PM / OPP: Remove cpufreq wrapper dependency on internal data
organization
  PM / OPP: Move cpufreq specific OPP functions out of generic OPP
library

 Documentation/cpu-freq/core.txt |   29 +++
 Documentation/power/opp.txt |   40 ++
 drivers/base/power/opp.c|   91 
 drivers/cpufreq/Makefile|2 +
 drivers/cpufreq/cpufreq_opp.c   |  110 +++
 include/linux/cpufreq.h |   21 
 include/linux/pm_opp.h  |   20 ---
 7 files changed, 167 insertions(+), 146 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_opp.c

-- 
1.7.9.5

--
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 0/2] Add support for sii9234 chip

[Tomasz Stanislawski]

On 05/04/2014 01:17 AM, Greg KH wrote:
 On Fri, Apr 11, 2014 at 01:48:28PM +0200, Tomasz Stanislawski wrote:
 Hi everyone,
 This patchset adds support for sii9234 HD Mobile Link Bridge.  The chip is 
 used
 to convert HDMI signal into MHL.  The driver enables HDMI output on Trats and
 Trats2 boards.

 The code is based on the driver [1] developed by:
Adam Hampson ahamp...@sta.samsung.com
Erik Gilling konk...@android.com
 with additional contributions from:
Shankar Bandal shanka...@samsung.com
Dharam Kumar dharam...@samsung.com

 The drivers architecture was greatly simplified and transformed into a form
 accepted (hopefully) by opensource community.  The main differences from
 original code are:
 * using single I2C client instead of 4 subclients
 * remove all logic non-related to establishing HDMI link
 * simplify error handling
 * rewrite state machine in interrupt handler
 * wakeup and discovery triggered by an extcon event
 * integrate with Device Tree

 For now, the driver is added to drivers/misc/ directory because it has 
 neigher
 userspace nor kernel interface.  The chip is capable of receiving and
 processing CEC events, so the driver may export an input device in /dev/ in 
 the
 future.  However CEC could be also handled by HDMI driver.

 I kindly ask for suggestions about the best location for this driver.
 
 It really is an extcon driver, so why not put it in drivers/extcon?  And
 that might solve any build issues you have if you don't select extcon in
 your .config file and try to build this code :)
 
 thanks,

Hi Greg,
Thank you for your comments.

As I understand, drivers/extcon contains only extcon providers.
This driver is an extcon client, so mentioned location may not be adequate.

I am surprised that there are no comments about this driver.
Sii9234 chip is present on many exynos based boards/phones
and HDMI subsystem will not work without this code.

Regards,
Tomasz Stanislawski

 
 greg k-h
 

--
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] PM / OPP: Remove cpufreq wrapper dependency on internal data organization

[Viresh Kumar]

On 5 May 2014 19:03, Nishanth Menon n...@ti.com wrote:
 diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
  int dev_pm_opp_init_cpufreq_table(struct device *dev,
 struct cpufreq_frequency_table **table)
  {
 -   struct device_opp *dev_opp;
 struct dev_pm_opp *opp;
 -   struct cpufreq_frequency_table *freq_table;
 -   int i = 0;
 +   struct cpufreq_frequency_table *freq_table = NULL;
 +   int i, max_opps, ret = 0;
 +   unsigned long rate;

 -   /* Pretend as if I am an updater */
 -   mutex_lock(dev_opp_list_lock);

What if opp is being added for some reason at the same time?
I hope we can surely see some awkward results, maybe some
NULL pointers invocations as well..
--
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] PM / OPP: Remove cpufreq wrapper dependency on internal data organization

[Nishanth Menon]

On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote:


 What if opp is being added for some reason at the same time?
 I hope we can surely see some awkward results, maybe some
 NULL pointers invocations as well..

we wont - rcu operations ensure that.
--
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] PM / OPP: Move cpufreq specific OPP functions out of generic OPP library

[Viresh Kumar]

On 5 May 2014 19:03, Nishanth Menon n...@ti.com wrote:
 CPUFreq specific helper functions for OPP (Operating Performance Points)
 now use generic OPP functions that allow CPUFreq to be be moved back
 into CPUFreq framework. This allows for independent modifications
 or future enhancements as needed isolated to just CPUFreq framework
 alone.

 Here, we just move relevant code and documentation to make this part of
 CPUFreq infrastructure.

 Cc: Rafael J. Wysocki r...@rjwysocki.net
 Cc: Viresh Kumar viresh.ku...@linaro.org
 Cc: Kevin Hilman khil...@deeprootsystems.com
 Cc: cpuf...@vger.kernel.org
 Cc: linux-samsung-soc@vger.kernel.org
 Cc: linux-o...@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux...@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
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] PM / OPP: Remove cpufreq wrapper dependency on internal data organization

[Viresh Kumar]

On 5 May 2014 19:55, Nishanth Menon n...@ti.com wrote:
 On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote:


 What if opp is being added for some reason at the same time?
 I hope we can surely see some awkward results, maybe some
 NULL pointers invocations as well..

 we wont - rcu operations ensure that.

Stupid !!

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
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 0/4] Introducing Exynos ChipId driver

[Arnd Bergmann]

On Monday 05 May 2014 18:23:55 Pankaj Dubey wrote:
 On 05/04/2014 12:02 AM, Arnd Bergmann wrote:
  Ideally this should be done by slightly restructuring the DT
  source to make all on-chip devices appear below the soc node.
 
 Currently I can't see soc nodes in exynos4 and exynos5 DT files.
 So isn't it should be a separate patch first to modify all exynos4
 exynos5 DT files to move all devices under soc node?
 In that case existing chipid node will be also moved under soc node.

Yes, that would be good. In fact the soc node could be identical
to the chipid node, effectively moving everything under chipid.

  We'd have to think a bit about how to best do this while
  preserving compatibility with existing dts files.
 
 Is it necessary in this case?
 As I have mentioned there is difference in bit-mask among exynos4
 and exynos5's chipid. So is this reason not sufficient to keep separate
 compatible for both?

Having two compatible values for exynos4 and exynos5 is not a problem,
and it absolutely makes sense to have more specific values in there
as well:

compatible = samsung,exynos4210-chipid, samsung,exynos4-chipid;

 Also even if we get some way to preserve existing compatibility, I afraid
 in chipid driver that implementation will not look good, at least I am not
 able to think of any good way. Any suggestions?

The compatibility I mean is to ensure everything keeps working if
the node is not present.

  Regarding patch 4, this is not what I meant when I asked for
  removing the soc_is_exynos* macros. You basically do a 1:1 replacement
  using a different interface, but you still have code that does
  things differently based on a global identification.
 I agree with what you are trying to say. But if you see recently we had some
 patches (cpu_idle.c: [2], pmu.c: [3])  to remove usage of such macros from
 exynos machine files. So only leftover files using these macros are exynos.c
 platsmp.c and pm.c.
 
 For exynos.c I have tried to remove soc_is_exynos4/exynos5 by matching with
 compatible string in patch 1 of this series. Please let me know if that is OK?

I've taken a closer look at that file now. My preferred solution
would be to go back to having two machine descriptors as it
was before Sachin Kamat's ARM: EXYNOS: Consolidate exynos4 and
exynos5 machine files, but keep it all in one file and consolidated
as much as possible, e.g.

static void __init exynos_dt_machine_init(void)
{
   exynos_cpuidle_init();
   exynos_cpufreq_init();

   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}

static void __init exynos5_dt_machine_init(void)
{
   /*
* Exynos5's legacy i2c controller and new high speed i2c
* controller have muxed interrupt sources. By default the
* interrupts for 4-channel HS-I2C controller are enabled.
* If node for first four channels of legacy i2c controller
* are available then re-configure the interrupts via the
* system register.
*/
   struct device_node *i2c_np;
   const char *i2c_compat = samsung,s3c2440-i2c;
   unsigned int tmp;
   int id;

   for_each_compatible_node(i2c_np, NULL, i2c_compat) {
  if (of_device_is_available(i2c_np)) {
id = of_alias_get_id(i2c_np, i2c);
if (id  4) {
  tmp = readl(EXYNOS5_SYS_I2C_CFG);
  writel(tmp  ~(0x1  id),  
EXYNOS5_SYS_I2C_CFG);
}
   }
   }

   exynos_dt_machine_init();
}

This way you can avoid having another check of the compatible node.
In the long run, all of the this code should go away: The cpuidle
and cpufreq drivers should become normal platform drivers that
get probed when the devices are present (just like it's required
for arm64 anyway), and the EXYNOS5_SYS_I2C_CFG register should
get set up by an appropriate driver, e.g. the i2c driver through
syscon, or a pinmux driver that changes the mux between the
sources based on DT information, whatever fits best.

Similarly for exynos_map_io(), with the sysram out of the picture,
it can be 

void __init exynos4_init_io(void)
{
debug_ll_io_init();
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
}

void __init exynos5_init_io(void)
{
debug_ll_io_init();
iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos4_iodesc));
}

but in the long run, it would be nicer to completely eliminate
exynos4_iodesc and exynos5_iodesc as well, and remove the init_io
functions. Note that debug_ll_io_init() is already called when
you have a NULL .map_io callback.

 Also for platsmp.c and pm.c I can think of following approaches
 1: Keep these macros till we get generic solution?
 2: Allow chipid driver to expose APIs to check SoC id and SoC revisions 
 till we get
 generic solution. So that at least we can remove #ifdef  based macros
 as soc_is_exynosXYZ.
 3: Use of of_flat_dt_is_compatible or similar APIs 

Re: [PATCH 0/4] Introducing Exynos ChipId driver

[Arnd Bergmann]

On Monday 05 May 2014 16:58:14 Arnd Bergmann wrote:
  Also for platsmp.c and pm.c I can think of following approaches
  1: Keep these macros till we get generic solution?
  2: Allow chipid driver to expose APIs to check SoC id and SoC revisions 
  till we get
  generic solution. So that at least we can remove #ifdef  based macros
  as soc_is_exynosXYZ.
  3: Use of of_flat_dt_is_compatible or similar APIs in these machine files 
  till we get
  generic solution. For some cases where we want to know SoC revision let us
  map chipid register and get revision there itself.
  
  Please let me know what approach you think will be good?
 
 I think 1 or 2 would be better than 3. Between those two, I'm undecided,
 but I think either way the SoC specific values would be better kept in the
 mach-samsung directory than in plat/cpu.h or linux/exynos-chipid.h.

Actually, a good compromise for now would be to add the chipid driver
to mach-exynos instead of drivers/bus. This way you can keep the uses
of the ID local to the exynos platform code until it's no longer needed.
Then it can get moved out to drivers/soc to be shared with arm64.

Arnd
--
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] ARM: dts: Add peach-pit board support

[Doug Anderson]

Arun,

On Mon, May 5, 2014 at 2:25 AM, Arun Kumar K arun...@samsung.com wrote:
 Adds the google peach-pit board dts file which uses
 exynos5420 SoC.

 Signed-off-by: Arun Kumar K arun...@samsung.com
 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
  arch/arm/boot/dts/Makefile |1 +
  arch/arm/boot/dts/exynos5420-peach-pit.dts |  147 
 
  2 files changed, 148 insertions(+)

Note that this has an implicit dependency upon
https://patchwork.kernel.org/patch/4101881/ (ARM: dts: Add pwmX_out
pinctrl nodes to Exynos5420).  Once that has landed then I think we're
good to go.

Reviewed-by: Doug Anderson diand...@chromium.org
--
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: dts: Add peach-pi board support

[Doug Anderson]

On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Well, if you can use the device tree of peach-pit board and boot peach-pi
 and vice-versa and it won't cause any hardware failures then I guess it's
 fine to keep this string.

I believe you can actually make it a good portion of the way through
boot, though a bunch of things (including graphics) won't work.  I
general I don't think it's all that different from exynos5.


 I don't think this is a good idea, because this is basically rendering
 this
 dts file useless, unless used with a bootloader that can actually inject
 correct values. I believe that some generic setup could be provided in
 the
 dts, so you could at least get the board running.


 I won't say that I care a whole lot, but I think that was what was
 agreed upon the other day.  Specifically Tom Rini of U-Boot was
 worried about the fact that U-Boot will read the memory node and
 totally clobber it.  He thought there might be cases where someone
 might _purposely_ not want U-Boot to do that.

 ...I would wonder what alternate bootloader you're imagining will
 actually run on this board and not do this?


 People should have the freedom to choose anything they want. We have also
 barebox and coreboot with ARM and even Exynos5 support (in coreboot), but
 people might want to use something completely exotic as well and the device
 tree should let them do so.

Fair enough.  Unless Tom cares about this enough to throw his opinion
in here, I guess our answer is that the memory node should have a sane
default and we'll expect the bootloader to put something better in if
it can properly probe memory.

In this case I guess it would be 2GB.

-Doug
--
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 0/4] Introducing Exynos ChipId driver

[Rob Herring]

On Sat, May 3, 2014 at 10:02 AM, Arnd Bergmann a...@arndb.de wrote:
 On Saturday 03 May 2014 15:11:36 Pankaj Dubey wrote:
 This patch series attempts to get rid of soc_is_exynos macros
 and eventually with the help of this series we can probably get
 rid of CONFIG_SOC_EXYNOS in near future.
 Each Exynos SoC has ChipID block which can give information about
 SoC's product Id and revision number. Currently we have single
 DT binding information for this as samsung,exynos4210-chipid.
 But Exynos4 and Exynos5 SoC series have one small difference in
 chip Id, with resepect to product id bit-masks. So it means we
 should have separate compatible string for these different series
 of SoCs. So I have created new binding information for handling
 this difference. Also currently I can think of putting this driver
 code under drivers/misc/ but suggestions are welcome.
 Also current form of driver is missing platfrom driver and needs
 init function to be called from machine file (either exynos.c or
 platsmp.c). I hope lot of suggestions and comments to improve this
 further.

 This patch series is based on Kukjin Kim's for-next (3.14_rc1 tag)
 and prepared on top of following patch series and it's dependent
 patch series.

 I think putting it into drivers/soc would be most appropriate.
 We already have a few drivers lined up that we want in there,
 although the directory currently doesn't exist.

 However, I would ask that you use the infrastructure provided by
 drivers/base/soc.c when you add this driver, to also make the
 information available to user space using a standard API.

Agreed.

 Ideally this should be done by slightly restructuring the DT
 source to make all on-chip devices appear below the soc node.
 We'd have to think a bit about how to best do this while
 preserving compatibility with existing dts files.

I don't agree. How is a block with chip ID info the parent of all the
other devices?

In doing some work to move default of_platform_populate out of
platforms, I noticed that most platforms using the soc device are
making it the parent of platform devices. I think this is either wrong
or all platforms should have a default soc device. It makes little
sense for some platforms to have a devices under a soc sysfs directory
while others do not. Or the location changes when a platform latter
adds the soc device.

Rob
--
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 v5 0/5] MCPM backend for Exynos5420

[Abhilash Kesavan]

This is v5 of the series adding MCPM backend support for SMP secondary boot
and core switching on Samsung's Exynos5420. The patches are based on the mcpm
support added for Exynos5420 in the Chromium kernel repository here:
https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.8

This patchset depends on:
- [v2,1/2] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings
(https://patchwork.kernel.org/patch/4101091/)

The patches have been prepared on linux-next(20140502) and tested on SMDK5420
EVT1 using the /dev/b.L_switcher user interface. Secondary core boot-up has
also been tested on an Exynos5420-based chromebook.

Changes since v4:
Addressed the following comments from Nicolas Pitre:
- Fixed the location of L2 prefetching disable code.
- Fixed the location of the TODO comment.
- Fixed a possible race in mcpm cluster state check in
  exynos_power_up().

Changes since v3:
- Rebased on top of the latest SYSRAM DT patchset from Sachin Kamat.

Addressed the following comments from Lorenzo Pieralisi and Nicolas Pitre:
- Dropped the patch arm: exynos: Add /dev/bL_status user interface on
  Exynos5420.
- Fixed the header ordering and removed unnecessary header inclusions.
- Made the code symmetric in exynos_cluster_power_control().
- Fixed the error path in exynos_power_up.
- Got rid of cnt variable used for last man checking.
- Removed stale comments.
- Replaced soc_is with of_find_compatible_node check for exynos5420.
- Added L2 prefetching disable code needed during A15 power down.

Changes since v2:
Addressed the following comments from Nicolas Pitre and Daniel Lezcano:
- Added generic common (cluster) configuration functions to pm.c
  which may be used by other subsystems.
- Removed unused cpumask variable in mcpm code.
- Re-worked exynos_power_down_finish() referencing the tc2_pm code.
- Removed the status checks in core and cluster power functions. We
  just set the power control bit and do not check the previous state
  anymore.
- Removed incorrect jiffies timeout usage in path where IRQs are
  disabled.

Changes since v1:
Addressed the following comments from Dave Martin and Nicolas Pitre:
- Fixed help text for EXYNOS5420_MCPM symbol.
- Removed mcpm-exynos-setup.S file and added similar code from tc2_pm.c.
- Changed the spinlock name from bl_lock to exynos_mcpm_lock.
- Removed snoop enable/disable calls due to possible cpuidle issue and
  not having numbers proving a significant power savings. Dropped the
  drivers/bus: arm-cci: Add common control interface for ACE ports
  patch from v1 as it was no longer needed.
- Created a macro for exynos-specific v7_exit_coherency_flush which
  handles an erratum. This was done to prevent duplication of code.
- Removed outer_flush_all call.
- Removed redundant dsb in power_down function.
- Removed unnecessary initialization of global variables to zero.
- Split the /dev/bL_status debug interface into another patch.
- Fixed error handling in exynos_mcpm_init().
- Called mcpm_smp_set_ops directly from exynos_mcpm_init().
- Added a TODO for supporting cluster down on exynos5420.

NOTE:
- Have added Leela Krishna's generic cpu power control function series
  as part of this patchset.
- Only the patch arm: exynos: Add MCPM call-back functions has changed
  from v3.
- I have tested with and without the erratum 799270 workaround and both
  work fine. I have kept the erratum fix for the time being.

Abhilash Kesavan (2):
  arm: exynos: Add generic cluster power control functions
  arm: exynos: Add MCPM call-back functions

Andrew Bresticker (1):
  ARM: dts: exynos5420: add CCI node

Leela Krishna Amudala (2):
  ARM: EXYNOS: Add generic cpu power control functions for all exynos
based SoCs
  ARM: EXYNOS: use generic exynos cpu power control functions

 arch/arm/boot/dts/exynos5420.dtsi  |   27 +++
 arch/arm/mach-exynos/Kconfig   |8 +
 arch/arm/mach-exynos/Makefile  |2 +
 arch/arm/mach-exynos/common.h  |6 +
 arch/arm/mach-exynos/mcpm-exynos.c |  344 
 arch/arm/mach-exynos/platsmp.c |9 +-
 arch/arm/mach-exynos/pm.c  |   66 +++
 arch/arm/mach-exynos/regs-pmu.h|   15 ++
 8 files changed, 471 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/mach-exynos/mcpm-exynos.c

-- 
1.7.9.5

--
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 v5 4/5] ARM: dts: exynos5420: add CCI node

[Abhilash Kesavan]

From: Andrew Bresticker abres...@chromium.org

Add device-tree bindings for the ARM CCI-400 on Exynos5420.  There
are two slave interfaces: one for the A15 cluster and one for the
A7 cluster.

Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
 arch/arm/boot/dts/exynos5420.dtsi |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index ff496ad..3140138 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -58,6 +58,7 @@
compatible = arm,cortex-a15;
reg = 0x0;
clock-frequency = 18;
+   cci-control-port = cci_control1;
};
 
cpu1: cpu@1 {
@@ -65,6 +66,7 @@
compatible = arm,cortex-a15;
reg = 0x1;
clock-frequency = 18;
+   cci-control-port = cci_control1;
};
 
cpu2: cpu@2 {
@@ -72,6 +74,7 @@
compatible = arm,cortex-a15;
reg = 0x2;
clock-frequency = 18;
+   cci-control-port = cci_control1;
};
 
cpu3: cpu@3 {
@@ -79,6 +82,7 @@
compatible = arm,cortex-a15;
reg = 0x3;
clock-frequency = 18;
+   cci-control-port = cci_control1;
};
 
cpu4: cpu@100 {
@@ -86,6 +90,7 @@
compatible = arm,cortex-a7;
reg = 0x100;
clock-frequency = 10;
+   cci-control-port = cci_control0;
};
 
cpu5: cpu@101 {
@@ -93,6 +98,7 @@
compatible = arm,cortex-a7;
reg = 0x101;
clock-frequency = 10;
+   cci-control-port = cci_control0;
};
 
cpu6: cpu@102 {
@@ -100,6 +106,7 @@
compatible = arm,cortex-a7;
reg = 0x102;
clock-frequency = 10;
+   cci-control-port = cci_control0;
};
 
cpu7: cpu@103 {
@@ -107,6 +114,26 @@
compatible = arm,cortex-a7;
reg = 0x103;
clock-frequency = 10;
+   cci-control-port = cci_control0;
+   };
+   };
+
+   cci@10d2 {
+   compatible = arm,cci-400;
+   #address-cells = 1;
+   #size-cells = 1;
+   reg = 0x10d2 0x1000;
+   ranges = 0x0 0x10d2 0x6000;
+
+   cci_control0: slave-if@4000 {
+   compatible = arm,cci-400-ctrl-if;
+   interface-type = ace;
+   reg = 0x4000 0x1000;
+   };
+   cci_control1: slave-if@5000 {
+   compatible = arm,cci-400-ctrl-if;
+   interface-type = ace;
+   reg = 0x5000 0x1000;
};
};
 
-- 
1.7.9.5

--
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 v5 1/5] ARM: EXYNOS: Add generic cpu power control functions for all exynos based SoCs

[Abhilash Kesavan]

From: Leela Krishna Amudala leela.kris...@linaro.org

Add generic cpu power control functions for exynos based SoCS
for cpu power up/down and to know the cpu status.

Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
---
 arch/arm/mach-exynos/common.h   |3 +++
 arch/arm/mach-exynos/pm.c   |   36 
 arch/arm/mach-exynos/regs-pmu.h |6 ++
 3 files changed, 45 insertions(+)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 47cbab0..a7dbb5f 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -63,5 +63,8 @@ struct exynos_pmu_conf {
 };
 
 extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void exynos_cpu_powerdown(int cpu);
+extern void exynos_cpu_powerup(int cpu);
+extern int  exynos_cpu_power_state(int cpu);
 
 #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..6651028 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -100,6 +100,42 @@ static int exynos_irq_set_wake(struct irq_data *data, 
unsigned int state)
return -ENOENT;
 }
 
+/**
+ * exynos_cpu_powerdown : power down the specified cpu
+ * @cpu : the cpu to power down
+ *
+ * Power downs the specified cpu. The sequence must be finished by a
+ * call to cpu_do_idle()
+ *
+ */
+void exynos_cpu_powerdown(int cpu)
+{
+   __raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_powerup : power up the specified cpu
+ * @cpu : the cpu to power up
+ *
+ * Power up the specified cpu
+ */
+void exynos_cpu_powerup(int cpu)
+{
+   __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_power_state : returns the power state of the cpu
+ * @cpu : the cpu to retrieve the power state from
+ *
+ */
+int exynos_cpu_power_state(int cpu)
+{
+   return (__raw_readl(EXYNOS_ARM_CORE_STATUS(cpu)) 
+   S5P_CORE_LOCAL_PWR_EN);
+}
+
 /* For Cortex-A9 Diagnostic and Power control register */
 static unsigned int save_arm_register[2];
 
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..0bdfcbc 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -121,6 +121,12 @@
 
 #define S5P_CHECK_SLEEP0x0BAD
 
+#define EXYNOS_ARM_CORE0_CONFIGURATION S5P_PMUREG(0x2000)
+#define EXYNOS_ARM_CORE_CONFIGURATION(_nr) \
+   (EXYNOS_ARM_CORE0_CONFIGURATION + (0x80 * (_nr)))
+#define EXYNOS_ARM_CORE_STATUS(_nr)\
+   (EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
+
 /* Only for EXYNOS4210 */
 #define S5P_CMU_CLKSTOP_LCD1_LOWPWRS5P_PMUREG(0x1154)
 #define S5P_CMU_RESET_LCD1_LOWPWR  S5P_PMUREG(0x1174)
-- 
1.7.9.5

--
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 v5 3/5] arm: exynos: Add generic cluster power control functions

[Abhilash Kesavan]

Add generic cluster power control functions for exynos based SoCS
for cluster power up/down and to know the cluster status.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
 arch/arm/mach-exynos/common.h   |3 +++
 arch/arm/mach-exynos/pm.c   |   30 ++
 arch/arm/mach-exynos/regs-pmu.h |6 ++
 3 files changed, 39 insertions(+)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index a7dbb5f..03b8bb2 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -66,5 +66,8 @@ extern void exynos_sys_powerdown_conf(enum sys_powerdown 
mode);
 extern void exynos_cpu_powerdown(int cpu);
 extern void exynos_cpu_powerup(int cpu);
 extern int  exynos_cpu_power_state(int cpu);
+extern void exynos_cluster_powerdown(int cluster);
+extern void exynos_cluster_powerup(int cluster);
+extern int  exynos_cluster_power_state(int cluster);
 
 #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 6651028..f02d864 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -136,6 +136,36 @@ int exynos_cpu_power_state(int cpu)
S5P_CORE_LOCAL_PWR_EN);
 }
 
+/**
+ * exynos_common_powerdown : power down the specified cluster
+ * @cluster : the cluster to power down
+ */
+void exynos_cluster_powerdown(int cluster)
+{
+   __raw_writel(0, EXYNOS_COMMON_CONFIGURATION(cluster));
+}
+
+/**
+ * exynos_cluster_powerup : power up the specified cluster
+ * @cluster : the cluster to power up
+ */
+void exynos_cluster_powerup(int cluster)
+{
+   __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+EXYNOS_COMMON_CONFIGURATION(cluster));
+}
+
+/**
+ * exynos_cluster_power_state : returns the power state of the cluster
+ * @cluster : the cluster to retrieve the power state from
+ *
+ */
+int exynos_cluster_power_state(int cluster)
+{
+   return (__raw_readl(EXYNOS_COMMON_STATUS(cluster)) 
+   S5P_CORE_LOCAL_PWR_EN);
+}
+
 /* For Cortex-A9 Diagnostic and Power control register */
 static unsigned int save_arm_register[2];
 
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 0bdfcbc..6685ebf 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -127,6 +127,12 @@
 #define EXYNOS_ARM_CORE_STATUS(_nr)\
(EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
 
+#define EXYNOS_ARM_COMMON_CONFIGURATIONS5P_PMUREG(0x2500)
+#define EXYNOS_COMMON_CONFIGURATION(_nr)   \
+   (EXYNOS_ARM_COMMON_CONFIGURATION + (0x80 * (_nr)))
+#define EXYNOS_COMMON_STATUS(_nr)  \
+   (EXYNOS_COMMON_CONFIGURATION(_nr) + 0x4)
+
 /* Only for EXYNOS4210 */
 #define S5P_CMU_CLKSTOP_LCD1_LOWPWRS5P_PMUREG(0x1154)
 #define S5P_CMU_RESET_LCD1_LOWPWR  S5P_PMUREG(0x1174)
-- 
1.7.9.5

--
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 v5 2/5] ARM: EXYNOS: use generic exynos cpu power control functions

[Abhilash Kesavan]

From: Leela Krishna Amudala leela.kris...@linaro.org

Use generic exynos cpu power control functions to power up/down
and to know the status of the cpu.

Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
---
 arch/arm/mach-exynos/platsmp.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 0aac032..d442a66 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -130,15 +130,12 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 */
write_pen_release(phys_cpu);
 
-   if (!(__raw_readl(S5P_ARM_CORE1_STATUS)  S5P_CORE_LOCAL_PWR_EN)) {
-   __raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
-
+   if (!exynos_cpu_power_state(cpu)) {
+   exynos_cpu_powerup(cpu);
timeout = 10;
 
/* wait max 10 ms until cpu1 is on */
-   while ((__raw_readl(S5P_ARM_CORE1_STATUS)
-S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
+   while (exynos_cpu_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
 
-- 
1.7.9.5

--
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 v5 5/5] arm: exynos: Add MCPM call-back functions

[Abhilash Kesavan]

Add machine-dependent MCPM call-backs for Exynos5420. These are used
to power up/down the secondary CPUs during boot, shutdown, s2r and
switching.

Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Inderpal Singh inderpa...@samsung.com
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
 arch/arm/mach-exynos/Kconfig   |8 +
 arch/arm/mach-exynos/Makefile  |2 +
 arch/arm/mach-exynos/mcpm-exynos.c |  344 
 arch/arm/mach-exynos/regs-pmu.h|3 +
 4 files changed, 357 insertions(+)
 create mode 100644 arch/arm/mach-exynos/mcpm-exynos.c

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 5c34dc2..138070e 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -73,4 +73,12 @@ config SOC_EXYNOS5440
 
 endmenu
 
+config EXYNOS5420_MCPM
+   bool Exynos5420 Multi-Cluster PM support
+   depends on MCPM  SOC_EXYNOS5420
+   select ARM_CCI
+   help
+ This is needed to provide CPU and cluster power management
+ on Exynos5420 implementing big.LITTLE.
+
 endif
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index a656dbe..01bc9b9 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -29,3 +29,5 @@ obj-$(CONFIG_ARCH_EXYNOS) += firmware.o
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_exynos-smc.o:=-Wa,-march=armv7-a$(plus_sec)
+
+obj-$(CONFIG_EXYNOS5420_MCPM)  += mcpm-exynos.o
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
b/arch/arm/mach-exynos/mcpm-exynos.c
new file mode 100644
index 000..e578007
--- /dev/null
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -0,0 +1,344 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * arch/arm/mach-exynos/mcpm-exynos.c
+ *
+ * Based on arch/arm/mach-vexpress/dcscb.c
+ *
+ * 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/arm-cci.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/of_address.h
+
+#include asm/cputype.h
+#include asm/cp15.h
+#include asm/mcpm.h
+
+#include regs-pmu.h
+#include common.h
+
+#define EXYNOS5420_CPUS_PER_CLUSTER4
+#define EXYNOS5420_NR_CLUSTERS 2
+
+/* Non-secure iRAM base address */
+static void __iomem *ns_sram_base_addr;
+
+/*
+ * The common v7_exit_coherency_flush API could not be used because of the
+ * Erratum 799270 workaround. This macro is the same as the common one (in
+ * arch/arm/include/asm/cacheflush.h) except for the erratum handling.
+ */
+#define exynos_v7_exit_coherency_flush(level) \
+   asm volatile( \
+   stmfd  sp!, {fp, ip}\n\t\
+   mrcp15, 0, r0, c1, c0, 0   @ get SCTLR\n\t \
+   bicr0, r0, #__stringify(CR_C)\n\t \
+   mcrp15, 0, r0, c1, c0, 0   @ set SCTLR\n\t \
+   isb\n\t\
+   bl v7_flush_dcache___stringify(level)\n\t \
+   clrex\n\t\
+   mrcp15, 0, r0, c1, c0, 1   @ get ACTLR\n\t \
+   bicr0, r0, #(1  6)   @ disable local coherency\n\t \
+   /* Dummy Load of a device register to avoid Erratum 799270 */ \
+   ldrr4, [%0]\n\t \
+   andr4, r4, #0\n\t \
+   orrr0, r0, r4\n\t \
+   mcrp15, 0, r0, c1, c0, 1   @ set ACTLR\n\t \
+   isb\n\t \
+   dsb\n\t \
+   ldmfd  sp!, {fp, ip} \
+   : \
+   : Ir (S5P_INFORM0) \
+   : r0, r1, r2, r3, r4, r5, r6, r7, \
+ r9, r10, lr, memory)
+
+/*
+ * We can't use regular spinlocks. In the switcher case, it is possible
+ * for an outbound CPU to call power_down() after its inbound counterpart
+ * is already live using the same logical CPU number which trips lockdep
+ * debugging.
+ */
+static arch_spinlock_t exynos_mcpm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int
+cpu_use_count[EXYNOS5420_CPUS_PER_CLUSTER][EXYNOS5420_NR_CLUSTERS];
+
+#define exynos_cluster_usecnt(cluster) \
+   (cpu_use_count[0][cluster] +   \
+cpu_use_count[1][cluster] +   \
+cpu_use_count[2][cluster] +   \
+cpu_use_count[3][cluster])
+
+#define exynos_cluster_unused(cluster) !exynos_cluster_usecnt(cluster)
+
+static int exynos_cluster_power_control(unsigned int cluster, int enable)
+{
+   unsigned int tries = 100;
+   unsigned int val;
+
+   if (enable) {
+   exynos_cluster_powerup(cluster);
+   val = S5P_CORE_LOCAL_PWR_EN;
+   } else {
+   exynos_cluster_powerdown(cluster);
+   val = 0;
+   }
+
+   /* Wait until cluster power control is applied */
+   while (tries--) {
+   if (exynos_cluster_power_state(cluster) == val)
+   return 0;
+
+   cpu_relax();
+   }
+   pr_warn(timed out waiting for cluster %u to 

Re: [RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq

[Olof Johansson]

On Tue, Apr 29, 2014 at 9:39 AM, Doug Anderson diand...@chromium.org wrote:
 Anton,

 On Wed, Apr 23, 2014 at 8:56 AM, Doug Anderson diand...@chromium.org wrote:
 On the ARM Chromebook tps65090 has two masters: the AP (the main
 processor running linux) and the EC (the embedded controller).  The AP
 is allowed to mess with FETs but the EC is in charge of charge control.

 The tps65090 interupt line is routed to both the AP and the EC, which
 can cause quite a headache.  Having two people adjusting masks and
 acking interrupts is a recipe for disaster.

 In the shipping kernel we had a hack to have the AP pay attention to
 the IRQ but not to ack it.  It also wasn't supposed to configure the
 IRQ in any way.  That hack allowed us to detect when the device was
 charging without messing with the EC's state.

 The current tps65090 infrastructure makes the above difficult, and it
 was a bit of a hack to begin with.  Rather than uglify the driver to
 support it, just extend the driver's existing notion of no irq to
 the charger.  This makes the charger code poll every 2 seconds for AC
 detect, which is sufficient.

 For proper functioning, requires (mfd: tps65090: Don't tell child
 devices we have an IRQ if we don't).  If we don't have that patch
 we'll simply fail to probe on devices without an interrupt (just like
 we did before this patch).

 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
 Changes in v3: None
 Changes in v2:
 - Split noirq (polling mode) changes into MFD and charger

  drivers/power/tps65090-charger.c | 76 
 +++-
  1 file changed, 59 insertions(+), 17 deletions(-)

 All the rest of this series has been acked and applied.  Do you have
 time to review this patch?

 Thanks!  :)

FWIW, I've seen very little email traffic from Anton this year, he
might have limited time for maintainership at the moment. Usually what
we do in these cases is that we give the maintainer as much time as
possible, but eventually if there's no action, and the patches look
reasonable, we apply them with the maintainer on Cc: line in the
signed-offs. Or we send them to/through akpm, which tends to be the
catch-all for high-latency maintainers, etc.

Since this patch isn't holding anything up, let's give Anton as much
time as possible to review, and revisit in ~2 weeks (so it has time to
land somewhere in time for the merge window).


-Olof
--
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 v5 5/5] arm: exynos: Add MCPM call-back functions

[Nicolas Pitre]

On Mon, 5 May 2014, Abhilash Kesavan wrote:

 Add machine-dependent MCPM call-backs for Exynos5420. These are used
 to power up/down the secondary CPUs during boot, shutdown, s2r and
 switching.
 
 Signed-off-by: Thomas Abraham thomas...@samsung.com
 Signed-off-by: Inderpal Singh inderpa...@samsung.com
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com

Reviewed-by: Nicolas Pitre ni...@linaro.org


 ---
  arch/arm/mach-exynos/Kconfig   |8 +
  arch/arm/mach-exynos/Makefile  |2 +
  arch/arm/mach-exynos/mcpm-exynos.c |  344 
 
  arch/arm/mach-exynos/regs-pmu.h|3 +
  4 files changed, 357 insertions(+)
  create mode 100644 arch/arm/mach-exynos/mcpm-exynos.c
 
 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index 5c34dc2..138070e 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -73,4 +73,12 @@ config SOC_EXYNOS5440
  
  endmenu
  
 +config EXYNOS5420_MCPM
 + bool Exynos5420 Multi-Cluster PM support
 + depends on MCPM  SOC_EXYNOS5420
 + select ARM_CCI
 + help
 +   This is needed to provide CPU and cluster power management
 +   on Exynos5420 implementing big.LITTLE.
 +
  endif
 diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
 index a656dbe..01bc9b9 100644
 --- a/arch/arm/mach-exynos/Makefile
 +++ b/arch/arm/mach-exynos/Makefile
 @@ -29,3 +29,5 @@ obj-$(CONFIG_ARCH_EXYNOS)   += firmware.o
  
  plus_sec := $(call as-instr,.arch_extension sec,+sec)
  AFLAGS_exynos-smc.o  :=-Wa,-march=armv7-a$(plus_sec)
 +
 +obj-$(CONFIG_EXYNOS5420_MCPM)+= mcpm-exynos.o
 diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
 b/arch/arm/mach-exynos/mcpm-exynos.c
 new file mode 100644
 index 000..e578007
 --- /dev/null
 +++ b/arch/arm/mach-exynos/mcpm-exynos.c
 @@ -0,0 +1,344 @@
 +/*
 + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
 + *   http://www.samsung.com
 + *
 + * arch/arm/mach-exynos/mcpm-exynos.c
 + *
 + * Based on arch/arm/mach-vexpress/dcscb.c
 + *
 + * 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/arm-cci.h
 +#include linux/delay.h
 +#include linux/io.h
 +#include linux/of_address.h
 +
 +#include asm/cputype.h
 +#include asm/cp15.h
 +#include asm/mcpm.h
 +
 +#include regs-pmu.h
 +#include common.h
 +
 +#define EXYNOS5420_CPUS_PER_CLUSTER  4
 +#define EXYNOS5420_NR_CLUSTERS   2
 +
 +/* Non-secure iRAM base address */
 +static void __iomem *ns_sram_base_addr;
 +
 +/*
 + * The common v7_exit_coherency_flush API could not be used because of the
 + * Erratum 799270 workaround. This macro is the same as the common one (in
 + * arch/arm/include/asm/cacheflush.h) except for the erratum handling.
 + */
 +#define exynos_v7_exit_coherency_flush(level) \
 + asm volatile( \
 + stmfd  sp!, {fp, ip}\n\t\
 + mrcp15, 0, r0, c1, c0, 0   @ get SCTLR\n\t \
 + bicr0, r0, #__stringify(CR_C)\n\t \
 + mcrp15, 0, r0, c1, c0, 0   @ set SCTLR\n\t \
 + isb\n\t\
 + bl v7_flush_dcache___stringify(level)\n\t \
 + clrex\n\t\
 + mrcp15, 0, r0, c1, c0, 1   @ get ACTLR\n\t \
 + bicr0, r0, #(1  6)   @ disable local coherency\n\t \
 + /* Dummy Load of a device register to avoid Erratum 799270 */ \
 + ldrr4, [%0]\n\t \
 + andr4, r4, #0\n\t \
 + orrr0, r0, r4\n\t \
 + mcrp15, 0, r0, c1, c0, 1   @ set ACTLR\n\t \
 + isb\n\t \
 + dsb\n\t \
 + ldmfd  sp!, {fp, ip} \
 + : \
 + : Ir (S5P_INFORM0) \
 + : r0, r1, r2, r3, r4, r5, r6, r7, \
 +   r9, r10, lr, memory)
 +
 +/*
 + * We can't use regular spinlocks. In the switcher case, it is possible
 + * for an outbound CPU to call power_down() after its inbound counterpart
 + * is already live using the same logical CPU number which trips lockdep
 + * debugging.
 + */
 +static arch_spinlock_t exynos_mcpm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
 +static int
 +cpu_use_count[EXYNOS5420_CPUS_PER_CLUSTER][EXYNOS5420_NR_CLUSTERS];
 +
 +#define exynos_cluster_usecnt(cluster) \
 + (cpu_use_count[0][cluster] +   \
 +  cpu_use_count[1][cluster] +   \
 +  cpu_use_count[2][cluster] +   \
 +  cpu_use_count[3][cluster])
 +
 +#define exynos_cluster_unused(cluster) !exynos_cluster_usecnt(cluster)
 +
 +static int exynos_cluster_power_control(unsigned int cluster, int enable)
 +{
 + unsigned int tries = 100;
 + unsigned int val;
 +
 + if (enable) {
 + exynos_cluster_powerup(cluster);
 + val = S5P_CORE_LOCAL_PWR_EN;
 + } else {
 + exynos_cluster_powerdown(cluster);
 + val = 0;
 + }
 +
 + /* Wait until cluster power control is applied */
 + while (tries--) {
 + if 

Re: [PATCH 3/3] ARM: dts: Add peach-pi board support

[Tom Rini]

On 05/05/2014 11:17 AM, Doug Anderson wrote:
 On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Well, if you can use the device tree of peach-pit board and boot peach-pi
 and vice-versa and it won't cause any hardware failures then I guess it's
 fine to keep this string.
 
 I believe you can actually make it a good portion of the way through
 boot, though a bunch of things (including graphics) won't work.  I
 general I don't think it's all that different from exynos5.
 
 
 I don't think this is a good idea, because this is basically rendering
 this
 dts file useless, unless used with a bootloader that can actually inject
 correct values. I believe that some generic setup could be provided in
 the
 dts, so you could at least get the board running.


 I won't say that I care a whole lot, but I think that was what was
 agreed upon the other day.  Specifically Tom Rini of U-Boot was
 worried about the fact that U-Boot will read the memory node and
 totally clobber it.  He thought there might be cases where someone
 might _purposely_ not want U-Boot to do that.

 ...I would wonder what alternate bootloader you're imagining will
 actually run on this board and not do this?


 People should have the freedom to choose anything they want. We have also
 barebox and coreboot with ARM and even Exynos5 support (in coreboot), but
 people might want to use something completely exotic as well and the device
 tree should let them do so.
 
 Fair enough.  Unless Tom cares about this enough to throw his opinion
 in here, I guess our answer is that the memory node should have a sane
 default and we'll expect the bootloader to put something better in if
 it can properly probe memory.
 
 In this case I guess it would be 2GB.

So, a memory node that says a size of 0 is a valid and long standing
(see PowerPC folks) way of saying please fill in my memory node value
for me due to any number of reasons for not knowing before hand how
much memory there is.  Any boot loader which cannot fill in the memory
node is going to have problems with the various boards (PowerPC, ARM and
other) which say my memory size is 0, I want this fixed up at run time.

The problem I was raising at the ELC BoF is that today we can't just
stop overwriting values in the non-zero case as many boards lie about
their memory size, in non-zero ways, but no one noticed as they only
tested with U-Boot which was performing the fixup.

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

[RFC V2 3/3] drm/bridge: ptn3460: support bridge chaining

[Ajay Kumar]

modify the driver to call the bridge-funcs of the next bridge
in the chain.
We assume that the bridge sitting next to ptn3460 is a bridge-panel.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
 drivers/gpu/drm/bridge/ptn3460.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index b171901..969869a 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -126,6 +126,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
 
+   if (bridge-next_bridge)
+   bridge-next_bridge-funcs-pre_enable(bridge-next_bridge);
/*
 * There's a bug in the PTN chip where it falsely asserts hotplug before
 * it is fully functional. We're forced to wait for the maximum start up
@@ -142,6 +144,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
 
 static void ptn3460_enable(struct drm_bridge *bridge)
 {
+   if (bridge-next_bridge)
+   bridge-next_bridge-funcs-enable(bridge-next_bridge);
 }
 
 static void ptn3460_disable(struct drm_bridge *bridge)
@@ -153,6 +157,11 @@ static void ptn3460_disable(struct drm_bridge *bridge)
 
ptn_bridge-enabled = false;
 
+   if (bridge-next_bridge) {
+   bridge-next_bridge-funcs-disable(bridge-next_bridge);
+   bridge-next_bridge-funcs-post_disable(bridge-next_bridge);
+   }
+
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
 
@@ -197,7 +206,10 @@ int ptn3460_get_modes(struct drm_connector *connector)
return drm_add_edid_modes(connector, ptn_bridge-edid);
 
power_off = !ptn_bridge-enabled;
-   ptn3460_pre_enable(ptn_bridge-bridge);
+   if (power_off) {
+   ptn3460_pre_enable(ptn_bridge-bridge);
+   ptn3460_enable(ptn_bridge-bridge);
+   }
 
edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!edid) {
@@ -219,8 +231,10 @@ int ptn3460_get_modes(struct drm_connector *connector)
num_modes = drm_add_edid_modes(connector, ptn_bridge-edid);
 
 out:
-   if (power_off)
+   if (power_off) {
ptn3460_disable(ptn_bridge-bridge);
+   ptn3460_post_disable(ptn_bridge-bridge);
+   }
 
return num_modes;
 }
@@ -318,14 +332,13 @@ int ptn3460_init(struct drm_device *dev, struct 
drm_encoder *encoder,
goto err;
}
 
-   ret = drm_bridge_init(dev, bridge, ptn3460_bridge_funcs);
+   ret = drm_bridge_init(dev, bridge, encoder, ptn3460_bridge_funcs);
if (ret) {
DRM_ERROR(Failed to initialize bridge with drm\n);
goto err;
}
 
bridge-driver_private = ptn_bridge;
-   encoder-bridge = bridge;
 
ret = drm_connector_init(dev, ptn_bridge-connector,
ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
-- 
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

[RFC V2 0/3] drm/bridge: panel and chaining

[Ajay Kumar]

This patchset is based on exynos-drm-next-todo branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

I have just put up Rob's and Sean's idea of chaining up the bridges
in code, and have implemented basic panel controls as a chained bridge.
This works well with ptn3460 bridge chip on exynos5250-snow board.

Still need to make use of standard list calls and figure out proper way
of deleting the bridge chain. So, this is just a rough version.

Ajay Kumar (3):
  [RFC V2 1/3] drm: implement chaining of drm bridges
  [RFC V2 2/3] drm/bridge: add a dummy panel driver to support lvds bridges
  [RFC V2 3/3] drm/bridge: ptn3460: support bridge chaining

 .../bindings/drm/bridge/bridge_panel.txt   |  45 
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/bridge_panel.c  | 240 +
 drivers/gpu/drm/bridge/ptn3460.c   |  21 +-
 drivers/gpu/drm/drm_crtc.c |  13 +-
 include/drm/bridge/bridge_panel.h  |  37 
 include/drm/drm_crtc.h |   2 +
 8 files changed, 360 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
 create mode 100644 drivers/gpu/drm/bridge/bridge_panel.c
 create mode 100644 include/drm/bridge/bridge_panel.h

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

[RFC V2 1/3] drm: implement chaining of drm bridges

[Ajay Kumar]

As of now, we can have only one bridge hanging off the encoder.
With this patch, we allow multiple bridges to hang onto the same encoder
with the use of a simple next_bridge ptr.

The drm core calls bridge-funcs for the first bridge which
is attached to it, and its upto the individual bridge drivers
to call bridge-funcs for the next bridge in the chain.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
 drivers/gpu/drm/drm_crtc.c | 13 -
 include/drm/drm_crtc.h |  2 ++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d8b7099..fe9905f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -918,8 +918,10 @@ EXPORT_SYMBOL(drm_connector_unplug_all);
  * Zero on success, error code on failure.
  */
 int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
-   const struct drm_bridge_funcs *funcs)
+   struct drm_encoder *encoder,
+   const struct drm_bridge_funcs *funcs)
 {
+   struct drm_bridge *temp;
int ret;
 
drm_modeset_lock_all(dev);
@@ -931,6 +933,15 @@ int drm_bridge_init(struct drm_device *dev, struct 
drm_bridge *bridge,
bridge-dev = dev;
bridge-funcs = funcs;
 
+   if (encoder-bridge) {
+   temp = encoder-bridge;
+   while (temp-next_bridge)
+   temp = temp-next_bridge;
+
+   temp-next_bridge = bridge;
+   } else
+   encoder-bridge = bridge;
+
list_add_tail(bridge-head, dev-mode_config.bridge_list);
dev-mode_config.num_bridge++;
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e55fccb..bb6ed88 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -619,6 +619,7 @@ struct drm_bridge_funcs {
 struct drm_bridge {
struct drm_device *dev;
struct list_head head;
+   struct drm_bridge *next_bridge;
 
struct drm_mode_object base;
 
@@ -862,6 +863,7 @@ extern void drm_connector_cleanup(struct drm_connector 
*connector);
 extern void drm_connector_unplug_all(struct drm_device *dev);
 
 extern int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
+  struct drm_encoder *encoder,
   const struct drm_bridge_funcs *funcs);
 extern void drm_bridge_cleanup(struct drm_bridge *bridge);
 
-- 
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

[RFC V2 2/3] drm/bridge: add a dummy panel driver to support lvds bridges

[Ajay Kumar]

implement basic panel controls as a drm_bridge so that
the existing bridges can make use of it.

The driver assumes that it is the last entity in the bridge chain.

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
 .../bindings/drm/bridge/bridge_panel.txt   |  45 
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/bridge_panel.c  | 240 +
 include/drm/bridge/bridge_panel.h  |  37 
 5 files changed, 329 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
 create mode 100644 drivers/gpu/drm/bridge/bridge_panel.c
 create mode 100644 include/drm/bridge/bridge_panel.h

diff --git a/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt 
b/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
new file mode 100644
index 000..0f916b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
@@ -0,0 +1,45 @@
+Simple panel interface for chaining along with bridges
+
+Required properties:
+  - compatible: drm-bridge,panel
+
+Optional properties:
+   -lcd-en-gpio:
+   eDP panel LCD poweron GPIO.
+   Indicates which GPIO needs to be powered up as output
+   to powerup/enable the switch to the LCD panel.
+   -led-en-gpio:
+   eDP panel LED enable GPIO.
+   Indicates which GPIO needs to be powered up as output
+   to enable the backlight.
+   -panel-pre-enable-delay:
+   delay value in ms required for panel_pre_enable process
+   Delay in ms needed for the eDP panel LCD unit to
+   powerup, and delay needed between panel_VCC and
+   video_enable.
+   -panel-enable-delay:
+   delay value in ms required for panel_enable process
+   Delay in ms needed for the eDP panel backlight/LED unit
+   to powerup, and delay needed between video_enable and
+   BL_EN.
+   -panel-disable-delay:
+   delay value in ms required for panel_disable process
+   Delay in ms needed for the eDP panel backlight/LED unit
+   powerdown, and delay needed between BL_DISABLE and
+   video_disable.
+   -panel-post-disable-delay:
+   delay value in ms required for panel_post_disable process
+   Delay in ms needed for the eDP panel LCD unit to
+   to powerdown, and delay between video_disable and
+   panel_VCC going down.
+
+Example:
+
+   bridge-panel {
+   compatible = drm-bridge,panel;
+   led-en-gpio = gpx3 0 1;
+   panel-pre-enable-delay = 40;
+   panel-enable-delay = 20;
+   panel-disable-delay = 20;
+   panel-post-disable-delay = 30;
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..654c5ea 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,3 +3,9 @@ config DRM_PTN3460
depends on DRM
select DRM_KMS_HELPER
---help---
+
+config DRM_BRIDGE_PANEL
+   tristate dummy bridge panel
+   depends on DRM
+   select DRM_KMS_HELPER
+   ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..bf433cf 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
 ccflags-y := -Iinclude/drm
 
 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_BRIDGE_PANEL) += bridge_panel.o
diff --git a/drivers/gpu/drm/bridge/bridge_panel.c 
b/drivers/gpu/drm/bridge/bridge_panel.c
new file mode 100644
index 000..807118a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/bridge_panel.c
@@ -0,0 +1,240 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/regulator/consumer.h
+
+#include drmP.h
+
+#include bridge/bridge_panel.h
+
+enum panel_state {
+   PRE_ENABLE,
+   ENABLE,
+   DISABLE,
+   POST_DISABLE,
+};
+
+struct bridge_panel {
+   struct drm_connectorconnector;
+   struct i2c_client   *client;
+   

Re: exynos4412: porting hdmiddc and hdmiphy node entries

[Tobias Jakobi]

Hello Tomasz,

thanks a lot for the support!

 The meaning of hdmiphy is ambiguous.
 In exynos4 spec there are _TWO_ components named HDMIPHY.
 The first one is a PLL that generates a clock for HDMI subsystem.
 This PLL is controlled by I2C.
 
 You can find an example of its bindings at:
 http://lists.freedesktop.org/archives/dri-devel/2013-October/047687.html
OK, that looks exactly like the bindings I currently have in the dts.


 The second one is HDMI's physical interface located in PMU unit.
 
 The exynos-simple-phy is dedicated to controller the former (component of 
 PMU).
 
 The 'phy' attribute in DT refers to the PLL.
 There is a debate if 'phy' should refer to I2C device itself or
 rather to I2C bus. Currently it refers to driverless instance
 of I2C device.
By 'driverless' you mean that the node isn't probed by any specific
driver code / the 'compatible' string isn't used anywhere in the kernel
(like it's currently the situation?)


 Somehow this doesn't look right. And indeed:
 https://patchwork.kernel.org/patch/4021121/

 At least for exynos5250 this node is not a child on an i2c adapter.
 
 This is a completely different HDMIPHY.
I'm not sure I understand. Different from the PPL and the PMU HDMIPHY?


 And yes, I would still have to add 'phys' and 'phy-names' to the hdmi
 node. This looks wrong again. Why do I have to specify 'phys' when I
 already have 'phy' there? Isn't that redundant?
 
 'phys' and 'phy-names' refers to PHY interfaces delivered by phy-core.
 The attribute named 'phy' refers to I2C device used to controller HDMI's PLL.
 The naming convention is very misleading.
Hmm, indeed this is very confusing. So with the move to
exynos-simple-phy, I guess I need these entries as well, am I correct?


 Well, you see, lots of confusion here. I would appreciate any kind of
 help on how to proceed here.
 
 The documentation for HDMI's bindings should be fixed.
Well, I can agree with that :)


With best wishes,
Tobias

--
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: dts: Add pwmX_out pinctrl nodes to Exynos5420

[Kukjin Kim]

Tomasz Figa wrote:
 
 Hi,
 
Hi,

 On 02.05.2014 17:44, Doug Anderson wrote:
  Arun,
 
  On Fri, May 2, 2014 at 5:48 AM, Arun Kumar K arun...@samsung.com wrote:
  Adds the PWM nodes to 5420 pinctrl dtsi file.
 
  Signed-off-by: Arun Kumar K arun...@samsung.com
  ---
arch/arm/boot/dts/exynos5420-pinctrl.dtsi |   28
 
1 file changed, 28 insertions(+)
 
  diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
 b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
  index e62c8eb..ba686e4 100644
  --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
  +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
  @@ -624,6 +624,34 @@
   samsung,pin-drv = 0;
   };
 
  +   pwm0_out: pwm0-out {
  +   samsung,pins = gpb2-0;
  +   samsung,pin-function = 2;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +
  +   pwm1_out: pwm1-out {
  +   samsung,pins = gpb2-1;
  +   samsung,pin-function = 2;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +
  +   pwm2_out: pwm2-out {
  +   samsung,pins = gpb2-2;
  +   samsung,pin-function = 2;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +
  +   pwm3_out: pwm3-out {
  +   samsung,pins = gpb2-3;
  +   samsung,pin-function = 2;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +
   i2c7_hs_bus: i2c7-hs-bus {
   samsung,pins = gpb2-2, gpb2-3;
   samsung,pin-function = 3;
 
  Possibly pwm3-out belongs below this one (since the start pin is
  larger than the start pin of i2c7-hs-bus).  Tomasz probably has a
  definite opinion on this.
 
 Well, I'm not opposed to keeping it as is. Having all the pwm nodes
 together might be even more readable.
 
+1 ;-)

 So feel free to add my Reviewed-by tag.
 
Thanks for you two guys' review.

Applied, thanks.

- Kukjin

--
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] ARM: dts: Add peach-pit board support

[Kukjin Kim]

Doug Anderson wrote:
 
 Arun,
 
 On Mon, May 5, 2014 at 2:25 AM, Arun Kumar K arun...@samsung.com wrote:
  Adds the google peach-pit board dts file which uses
  exynos5420 SoC.
 
  Signed-off-by: Arun Kumar K arun...@samsung.com
  Signed-off-by: Doug Anderson diand...@chromium.org
  ---
   arch/arm/boot/dts/Makefile |1 +
   arch/arm/boot/dts/exynos5420-peach-pit.dts |  147
 
   2 files changed, 148 insertions(+)
 
 Note that this has an implicit dependency upon
 https://patchwork.kernel.org/patch/4101881/ (ARM: dts: Add pwmX_out
 pinctrl nodes to Exynos5420).  Once that has landed then I think we're
 good to go.
 
 Reviewed-by: Doug Anderson diand...@chromium.org

Hi,

Thanks for Arun's re-spin and Tomasz and Doug's review.

Applied 1st and this.

Thanks,
Kukjin

--
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: dts: Add rear camera nodes for Exynos4412 Trats2 board

[Kukjin Kim]

Sylwester Nawrocki wrote:
 
 This patch enables the rear facing camera (s5c73m3) on TRATS2 board
 by adding the I2C0 bus controller, s5c73m3 sensor, MIPI CSI-2 receiver
 and the sensor's voltage regulator supply nodes.
 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  arch/arm/boot/dts/exynos4412-trats2.dts |   72
 +--
  1 file changed, 69 insertions(+), 3 deletions(-)
 
Applied, thanks.

- Kukjin

--
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: dts: exynos4: Update camera nodes for Trats2 board

[Kukjin Kim]

Sylwester Nawrocki wrote:
 
 Remove unused /camera/clock-controller node and add required clock
 properties to the camera node. This is required for a clock provider
 that will be referenced by image sensor devices.
 Also add required clock related changes to s5k6a3 device node and
 afvdd regulator supply.
 
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/boot/dts/exynos4.dtsi  |6 ++
  arch/arm/boot/dts/exynos4412-trats2.dts |5 +++--
  2 files changed, 5 insertions(+), 6 deletions(-)
 
Applied, thanks.

- Kukjin

--
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: dts: exynos4412-trats2: rename alias for i2c_ak8975 label

[Kukjin Kim]

Tomasz Figa wrote:
 
 Hi Tomasz,
 
 On 15.04.2014 16:25, Tomasz Stanislawski wrote:
  The i2c_ak8975 controler uses label i2c8.
  This alias is already used for I2C controller 8 defined
  in file arch/arm/boot/dts/exynos4.dtsi.
 
  This patch renames a label for i2c_ak8975 to i2c9.
 
  Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
  ---
arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
 b/arch/arm/boot/dts/exynos4412-trats2.dts
  index c16b315..5add765 100644
  --- a/arch/arm/boot/dts/exynos4412-trats2.dts
  +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
  @@ -20,7 +20,7 @@
  compatible = samsung,trats2, samsung,exynos4412,
 samsung,exynos4;
 
  aliases {
  -   i2c8 = i2c_ak8975;
  +   i2c9 = i2c_ak8975;
  };
 
  memory {
  --
  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
 
 
 Seems reasonable.
 
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 
Applied, thanks.

- Kukjin

--
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 0/4] ARM: S3C24XX: cleanup debug macro/earlyprintk

[Kukjin Kim]

Heiko Stübner wrote:
 
 This series tries to simplify the s3c24xx debug macro, removing
 dependencies
 on mach/ includes, static mappings and finally moving it into
 include/debug.
 
I think, it's good way :)

 The one slightly invasive change is the need for the developer to select
 the uart type by himself, which gets rid of the debug macro trying to
 determine the uart type itself.
 
 But as usage of the debug-uart is not the common case - especially in a
 multiplatform scenario - I didn't worry to much.
 
Yeah, I also don't want s3c24xx to support multiplatform in near future.

 Based on 3.15-rc1 and tested on a S3C2442 Openmoko Freerunner (GTA02)
 
 changes since v1:
 - do not introduce a secondary choice option, instead implement the
   s3c2410 debug uarts as separate options
 
 Heiko Stuebner (4):
   ARM: compressed/head.S: remove s3c24xx special case
   ARM: S3C24XX: trim down debug uart handling
   ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro
   ARM: S3C24XX: move debug-macro.S into the common space
 
  arch/arm/Kconfig.debug   |  54 +++-
  arch/arm/boot/compressed/head.S  |   5 --
  arch/arm/include/debug/s3c24xx.S |  46 +++
  arch/arm/mach-s3c24xx/Kconfig|  28 ---
  arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 101 --
 -
  5 files changed, 98 insertions(+), 136 deletions(-)
  create mode 100644 arch/arm/include/debug/s3c24xx.S
  delete mode 100644 arch/arm/mach-s3c24xx/include/mach/debug-macro.S
 
 --
 1.9.0

Basically I'm OK on this series but need to get review from Russell?

Thanks,
Kukjin

--
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 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf

[Kukjin Kim]

Heiko Stübner wrote:
 

[...]

  Anyway, Heiko, thanks for working on this. I'll try to review rest of
  the series soon. (I'm attending the ELC next week, though, so I'm not
  sure if I find some time then, though.)
 
Yeah, this series is really good to us.

 Just as a reminder, there isn't this much to still review, as you
 Acked/Reviewed most of the series in v1 and only this patch as well as 2
 and 5
 still need a review/ack - and the only changes are fixes for your
 comments ;-)
 
I think so. Since I will apply this series in this week, if any big
comments, please let us know.

Heiko, thanks for the v2.1 as well.

- Kukjin

--
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: S3C24XX: remove SAMSUNG_CLOCK remnants after ccf conversion

[Kukjin Kim]

Heiko Stübner wrote:
 
 This finally removes all remaining SAMSUNG_CLOCK conditional code
 from s3c24xx architectures.
 
 Signed-off-by: Heiko Stuebner he...@sntech.de
 ---
 This is of course meant to go on top of the s3c2410 ccf conversion
 
  arch/arm/mach-s3c24xx/Kconfig |  5 -
  arch/arm/mach-s3c24xx/common.c| 17 -
  arch/arm/mach-s3c24xx/cpufreq-utils.c |  6 --
  arch/arm/mach-s3c24xx/mach-anubis.c   | 27 ---
  arch/arm/mach-s3c24xx/mach-bast.c | 27 ---
  arch/arm/mach-s3c24xx/mach-osiris.c   | 27 ---
  arch/arm/mach-s3c24xx/mach-rx1950.c   | 14 --
  arch/arm/mach-s3c24xx/mach-vr1000.c   | 27 ---
  arch/arm/mach-s3c24xx/pm.c| 12 
  9 files changed, 162 deletions(-)
 
At last, we're supporting common clock framework for s3c24xx.

Heiko, very thanks for your effort.

Will apply with your previous s3c24xx ccf series.

- Kukjin

--
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: [RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq

[Anton Vorontsov]

On Mon, May 05, 2014 at 09:51:28AM -0700, Olof Johansson wrote:
  All the rest of this series has been acked and applied.  Do you have
  time to review this patch?
 
  Thanks!  :)
 
 FWIW, I've seen very little email traffic from Anton this year, he
 might have limited time for maintainership at the moment.

Yup.

commit 573189354b7c97cd2256b87cf083ee435584594e
Author: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Date:   Tue Jan 21 03:33:09 2014 +0400

MAINTAINERS: Pick up power supply maintainership

Anton stated that he would have to abandon power supply maintainership
due to the lack of time. By agreement with him and David, pick up power
supply tree.

Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Acked-by: Anton Vorontsov an...@enomsg.org
--
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