[PATCH v6 1/5] drm/exynos: add super device support

2014-04-17 Thread Inki Dae
This patch adds super device support to bind sub drivers
using device tree.

For this, you should add a super device node to each machine dt files
like belows,

In case of using MIPI-DSI,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>, <&dsi>;
};

In case of using DisplayPort,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>, <&dp>;
};

In case of using Parallel panel,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <&fimd>;
};

And if you don't add connector device node to ports property,
default parallel panel driver, exynos_drm_dpi module, will be used.

ports property can have the following device nodes,
fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI

With this patch, we can resolve the probing order issue without
some global lists. So this patch also removes the unnecessary lists and
stuff related to these lists.

Previous RFC patch,
 http://www.spinics.net/lists/dri-devel/msg54671.html

Changelog since RFC patch:
- Register sub drivers and probe them at load(). In case of non sub
  drivers, sub driver probe is needed.
- Enable runtime pm at fimd_probe() instead of fimd_bind(). runtime pm
  should be enabled before iommu device is attached to fimd device.
- Do not return an error with component_master_add fail.
- Remove super device support from mipi dsi driver which was in RFC.
- Add super device support to parallel driver.

Changelog v2:
- Add super device support to mipi dsi driver.
- Bind fimd driver only in case that a drm_panel for parallel panel driver
  is added to panel_list of drm_panel module.
- Change super node name to 'display-subsystem'
  . 'exynos-drm' is specific to Linux so change it to generic name.
- Change propery name of super node to 'ports'
  . crtcs and connectors propery names are also specific to Linux so
change them to generic name.

Changlog v3:
- Do not probe/remove dpi module if fimd node has no port node.

Changelog v4:
- Move some codes for getting resources from each bind function to
  each probe function.
  . if -EPROBE_DEFER is returned at bind context, components will be
bound and unbound repeatedly by deferred probe feature.

Changelog v5:
- Return error only in case that there is no any compoment attached
  to master.
- Add legacy dt binding support
- Probe vidi driver in exynos_drm_init(), and release vidi driver
  correctly.
- Remove duplicated coherent_dma_mask setting.

Changelog v6:
- Add super device support, and remove existing specific codes.
- Re-based on top of below patch series,
http://www.spinics.net/lists/dri-devel/msg57673.html

Signed-off-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |4 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  119 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |7 --
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |4 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c |4 +-
 drivers/gpu/drm/exynos/exynos_mixer.c|4 +-
 7 files changed, 69 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a97840c..1cc3981 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1313,12 +1313,12 @@ static const struct component_ops exynos_dp_ops = {
 
 static int exynos_dp_probe(struct platform_device *pdev)
 {
-   return exynos_drm_component_add(&pdev->dev, &exynos_dp_ops);
+   return component_add(&pdev->dev, &exynos_dp_ops);
 }
 
 static int exynos_dp_remove(struct platform_device *pdev)
 {
-   exynos_drm_component_del(&pdev->dev, &exynos_dp_ops);
+   component_del(&pdev->dev, &exynos_dp_ops);
return 0;
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ab8ffbb..1d653f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -43,14 +43,6 @@
 
 static struct platform_device *exynos_drm_pdev;
 
-static DEFINE_MUTEX(drm_component_lock);
-static LIST_HEAD(drm_component_list);
-
-struct component_dev {
-   struct list_head list;
-   struct device *dev;
-};
-
 static int exynos_drm_load(struct drm_device *dev, unsigned long flags)
 {
struct exynos_drm_private *private;
@@ -382,78 +374,72 @@ static const struct dev_pm_ops exynos_drm_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_sys_suspend, exynos_drm_sys_resume)
 };
 
-int exynos_drm_component_add(struct device *dev,
-   const struct component_ops *ops)
+static int compare_of(struct device *dev, void *data)
 {
-   struct component_dev *cdev;
-   int ret;
-
-   cdev =

[PATCH 5/5] exynos/drm: add DT bindings for super device node

2014-04-17 Thread Inki Dae
This patch adds bindings for Exynos drm display subsystem.
The bindings describes ports containing a list of phandles
pointing to display controller, image enhancer, and display
interfaces nodes.

Signed-off-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt

diff --git 
a/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt 
b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
new file mode 100644
index 000..6f7fae0
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
@@ -0,0 +1,32 @@
+Samsung Exynos DRM master device
+
+
+The Samsung Exynos DRM master device is a virtual device needed to list all
+display controller, image enhancer, and display interface nodes that comprise
+the graphics subsystem.
+
+Required properties:
+- compatible: Should be "samsung,exynos-display-subsystem"
+- ports: Should contain a list of phandles pointing to display controller,
+  image enhancer, and display interface ports.
+
+Examples:
+
+In case of using MIPI-DSI,
+display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <&fimd>, <&dsi>;
+};
+
+
+In case of using DisplayPort,
+display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <&fimd>, <&dp>;
+};
+
+In case of using parallel panel,
+display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <&fimd>;
+};
-- 
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 3/5] ARM: dts: exynos4210-trats: add super device node for exynos drm

2014-04-17 Thread Inki Dae
Signed-off-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos4210-trats.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 02c6768..a41c109 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -414,6 +414,11 @@
status = "okay";
};
 
+   display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <&fimd>, <&dsi_0>;
+   };
+
camera {
pinctrl-names = "default";
pinctrl-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 4/5] ARM: dts: exynos4412-trats2: add super device node for exynos drm

2014-04-17 Thread Inki Dae
Signed-off-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos4412-trats2.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 53c717b..115b9ed 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -581,6 +581,11 @@
status = "okay";
};
 
+   display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <&fimd>, <&dsi_0>;
+   };
+
camera {
pinctrl-0 = <&cam_port_b_clk_active>;
pinctrl-names = "default";
-- 
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 2/5] ARM: dts: exynos4210-universal: add super device node for exynos drm

2014-04-17 Thread Inki Dae
Signed-off-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos4210-universal_c210.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 0a80a72..5351ac4 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -409,6 +409,11 @@
};
};
 
+   display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <&fimd>;
+   };
+
pwm@139D {
compatible = "samsung,s5p6440-pwm";
status = "okay";
-- 
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 0/5] add super device node support

2014-04-17 Thread Inki Dae
This patch series adds super device node approach and relevant
dt bindings, and rebased on top of below patch series,
   http://www.spinics.net/lists/dri-devel/msg57673.html

Thanks,
Inki Dae

Inki Dae (5):
  drm/exynos: add super device support
  ARM: dts: exynos4210-universal: add super device node for exynos drm
  ARM: dts: exynos4210-trats: add super device node for exynos drm
  ARM: dts: exynos4412-trats2: add super device node for exynos drm
  exynos/drm: add DT bindings for super device node

 .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 ++
 arch/arm/boot/dts/exynos4210-trats.dts |5 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts|5 +
 arch/arm/boot/dts/exynos4412-trats2.dts|5 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|4 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  119 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h|7 --
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|4 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |4 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |4 +-
 drivers/gpu/drm/exynos/exynos_mixer.c  |4 +-
 11 files changed, 116 insertions(+), 77 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt

-- 
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 v2 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

2014-04-17 Thread Jungseok Lee
On Thursday, April 17, 2014 9:13 PM, Marc Zyngier wrote:
> On Wed, Apr 16 2014 at  5:33:31 am BST, Jungseok Lee  
> wrote:
> > This patch adds 4 levels of translation tables implementation for both
> > HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4
> > levels guest can run on ARMv8 architecture as introducing this feature.
> 
> Just to be sure: have you tested it with asymetric configurations (4kB host, 
> 64kB guest, and the
> oposite configuration)?

Dear Marc

Yes, I've tested all asymmetric configurations using 4K+3Level, 4K+4Level
and 64K+2Level. I will add all test configurations in the commit message
from the next version.

> > Signed-off-by: Jungseok Lee 
> > Reviewed-by: Sungjinn Chung 
> > ---
> >  arch/arm/include/asm/kvm_mmu.h   |   10 +
> >  arch/arm/kvm/mmu.c   |   88 
> > +-
> >  arch/arm64/include/asm/kvm_arm.h |   20 +
> >  arch/arm64/include/asm/kvm_mmu.h |   10 +
> >  4 files changed, 117 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/kvm_mmu.h
> > b/arch/arm/include/asm/kvm_mmu.h index 5c7aa3c..6f7906e 100644
> > --- a/arch/arm/include/asm/kvm_mmu.h
> > +++ b/arch/arm/include/asm/kvm_mmu.h
> > @@ -37,6 +37,11 @@
> >   */
> >  #define TRAMPOLINE_VA  UL(CONFIG_VECTORS_BASE)
> >
> > +/*
> > + * NUM_OBJS depends on the number of page table translation levels
> > +*/
> > +#define NUM_OBJS   2
> 
> I'm afraid this is way too generic. Use something along the lines of 
> MMU_CACHE_MIN_PAGES, that makes
> it obvious what we're talking about.

Okay, I will change it.

> > +
> >  #ifndef __ASSEMBLY__
> >
> >  #include 
> > @@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
> > clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));  }
> >
> > +static inline void kvm_clean_pmd(pmd_t *pmd) {
> > +   clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t)); }
> > +
> >  static inline void kvm_clean_pmd_entry(pmd_t *pmd)  {
> > clean_pmd_entry(pmd);
> > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index
> > 80bb1e6..7fc9e55 100644
> > --- a/arch/arm/kvm/mmu.c
> > +++ b/arch/arm/kvm/mmu.c
> > @@ -388,13 +388,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, 
> > unsigned long start,
> > return 0;
> >  }
> >
> > +static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
> > +  unsigned long end, unsigned long pfn,
> > +  pgprot_t prot)
> > +{
> > +   pud_t *pud;
> > +   pmd_t *pmd;
> > +   unsigned long addr, next;
> > +
> > +   addr = start;
> > +   do {
> > +   pud = pud_offset(pgd, addr);
> > +
> > +   if (pud_none_or_clear_bad(pud)) {
> > +   pmd = pmd_alloc_one(NULL, addr);
> > +   if (!pmd) {
> > +   kvm_err("Cannot allocate Hyp pmd\n");
> > +   return -ENOMEM;
> > +   }
> > +   pud_populate(NULL, pud, pmd);
> > +   get_page(virt_to_page(pud));
> > +   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> > +   }
> > +
> > +   next = pud_addr_end(addr, end);
> > +
> > +   create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> > +   pfn += (next - addr) >> PAGE_SHIFT;
> > +   } while (addr = next, addr != end);
> > +
> > +   return 0;
> > +}
> > +
> >  static int __create_hyp_mappings(pgd_t *pgdp,
> >  unsigned long start, unsigned long end,
> >  unsigned long pfn, pgprot_t prot)  {
> > pgd_t *pgd;
> > pud_t *pud;
> > -   pmd_t *pmd;
> > unsigned long addr, next;
> > int err = 0;
> >
> > @@ -403,22 +434,23 @@ static int __create_hyp_mappings(pgd_t *pgdp,
> > end = PAGE_ALIGN(end);
> > do {
> > pgd = pgdp + pgd_index(addr);
> > -   pud = pud_offset(pgd, addr);
> >
> > -   if (pud_none_or_clear_bad(pud)) {
> > -   pmd = pmd_alloc_one(NULL, addr);
> > -   if (!pmd) {
> > -   kvm_err("Cannot allocate Hyp pmd\n");
> > +   if (pgd_none(*pgd)) {
> > +   pud = pud_alloc_one(NULL, addr);
> > +   if (!pud) {
> > +   kvm_err("Cannot allocate Hyp pud\n");
> > err = -ENOMEM;
> > goto out;
> > }
> > -   pud_populate(NULL, pud, pmd);
> > -   get_page(virt_to_page(pud));
> > -   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> > +   pgd_populate(NULL, pgd, pud);
> > +   get_page(virt_to_page(pgd));
> > +   kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
> > }
> >
> > next = pgd_addr_end(addr, end);
> > -   err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> > +
> > +   err = cr

[PATCH 1/2] cpufreq: exynos: Use dev_err/info function instead of pr_err/info

2014-04-17 Thread Chanwoo Choi
This patch uses dev_err/info function to show accurate log message with device 
name
instead of pr_err/info function.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 drivers/cpufreq/exynos-cpufreq.c | 21 -
 drivers/cpufreq/exynos-cpufreq.h |  1 +
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f99cfe2..8b4bb4a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -49,6 +49,7 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
struct cpufreq_policy *policy = cpufreq_cpu_get(0);
unsigned int arm_volt, safe_arm_volt = 0;
unsigned int mpll_freq_khz = exynos_info->mpll_freq_khz;
+   struct device *dev = exynos_info->dev;
unsigned int old_freq;
int index, old_index;
int ret = 0;
@@ -90,8 +91,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
/* Firstly, voltage up to increase frequency */
ret = regulator_set_voltage(arm_regulator, arm_volt, arm_volt);
if (ret) {
-   pr_err("%s: failed to set cpu voltage to %d\n",
-   __func__, arm_volt);
+   dev_err(dev, "failed to set cpu voltage to %d\n",
+   arm_volt);
return ret;
}
}
@@ -100,8 +101,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
ret = regulator_set_voltage(arm_regulator, safe_arm_volt,
  safe_arm_volt);
if (ret) {
-   pr_err("%s: failed to set cpu voltage to %d\n",
-   __func__, safe_arm_volt);
+   dev_err(dev, "failed to set cpu voltage to %d\n",
+   safe_arm_volt);
return ret;
}
}
@@ -115,8 +116,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
ret = regulator_set_voltage(arm_regulator, arm_volt,
arm_volt);
if (ret) {
-   pr_err("%s: failed to set cpu voltage to %d\n",
-   __func__, arm_volt);
+   dev_err(dev, "failed to set cpu voltage to %d\n",
+   arm_volt);
goto out;
}
}
@@ -163,6 +164,8 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
if (!exynos_info)
return -ENOMEM;
 
+   exynos_info->dev = &pdev->dev;
+
if (soc_is_exynos4210())
ret = exynos4210_cpufreq_init(exynos_info);
else if (soc_is_exynos4212() || soc_is_exynos4412())
@@ -176,13 +179,13 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
goto err_vdd_arm;
 
if (exynos_info->set_freq == NULL) {
-   pr_err("%s: No set_freq function (ERR)\n", __func__);
+   dev_err(&pdev->dev, "No set_freq function (ERR)\n");
goto err_vdd_arm;
}
 
arm_regulator = regulator_get(NULL, "vdd_arm");
if (IS_ERR(arm_regulator)) {
-   pr_err("%s: failed to get resource vdd_arm\n", __func__);
+   dev_err(&pdev->dev, "failed to get resource vdd_arm\n");
goto err_vdd_arm;
}
 
@@ -192,7 +195,7 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
if (!cpufreq_register_driver(&exynos_driver))
return 0;
 
-   pr_err("%s: failed to register cpufreq driver\n", __func__);
+   dev_err(&pdev->dev, "failed to register cpufreq driver\n");
regulator_put(arm_regulator);
 err_vdd_arm:
kfree(exynos_info);
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 3ddade8..b72ff10 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -34,6 +34,7 @@ struct apll_freq {
 };
 
 struct exynos_dvfs_info {
+   struct device   *dev;
unsigned long   mpll_freq_khz;
unsigned intpll_safe_idx;
struct clk  *cpu_clk;
-- 
1.8.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 2/2] cpufreq: exynos: Add new Exynos3250 cpufreq driver

2014-04-17 Thread Chanwoo Choi
This patch add new Exynos3250 cpufreq driver to support DVFS (Dynamic Voltage
Frequency Scaling). Exynos3250 uses the Cortex-A7 dual cores and has a target
speed of 1.0 GHz. Exynos3250 cpufreq driver has range from 100MHz to 1000MHz.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 drivers/cpufreq/Kconfig.arm  |  11 +++
 drivers/cpufreq/Makefile |   1 +
 drivers/cpufreq/exynos-cpufreq.c |   4 +-
 drivers/cpufreq/exynos-cpufreq.h |  17 
 drivers/cpufreq/exynos3250-cpufreq.c | 158 +++
 5 files changed, 190 insertions(+), 1 deletion(-)
 create mode 100644 drivers/cpufreq/exynos3250-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0e9cce8..8af1bd1 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -28,6 +28,17 @@ config ARM_VEXPRESS_SPC_CPUFREQ
 config ARM_EXYNOS_CPUFREQ
bool
 
+config ARM_EXYNOS3250_CPUFREQ
+   bool "SAMSUNG EXYNOS3250"
+   depends on SOC_EXYNOS3250 && !ARCH_MULTIPLATFORM
+   default y
+   select ARM_EXYNOS_CPUFREQ
+   help
+ This adds the CPUFreq driver for Samsung EXYNOS3250 SoC based on
+ Cortex-A7 dual-core.
+
+ If in doubt, say N.
+
 config ARM_EXYNOS4210_CPUFREQ
bool "SAMSUNG EXYNOS4210"
depends on CPU_EXYNOS4210 && !ARCH_MULTIPLATFORM
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 0dbb963..18260bb 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)   += 
arm_big_little_dt.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)   += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += exynos-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS3250_CPUFREQ)   += exynos3250-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 8b4bb4a..e72cc60 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -166,7 +166,9 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
 
exynos_info->dev = &pdev->dev;
 
-   if (soc_is_exynos4210())
+   if (soc_is_exynos3250())
+   ret = exynos3250_cpufreq_init(exynos_info);
+   else if (soc_is_exynos4210())
ret = exynos4210_cpufreq_init(exynos_info);
else if (soc_is_exynos4212() || soc_is_exynos4412())
ret = exynos4x12_cpufreq_init(exynos_info);
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index b72ff10..9c5e491 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -26,6 +26,15 @@ enum cpufreq_level_index {
.mps = ((m) << 16 | (p) << 8 | (s)), \
}
 
+#define APLL_FREQ_EXYNOS3(f, a0, a1, a2, a3, a4, a5, b0, b1, b2, m, p, s) \
+   { \
+   .freq = (f) * 1000, \
+   .clk_div_cpu0 = ((a0) | (a1) << 4 |  (a2) << 16 | (a3) << 20 | \
+   (a4) << 24 | (a5) << 28), \
+   .clk_div_cpu1 = (b0 << 0 | b1 << 4 | b2 << 8), \
+   .mps = ((m) << 16 | (p) << 8 | (s)), \
+   }
+
 struct apll_freq {
unsigned int freq;
u32 clk_div_cpu0;
@@ -44,6 +53,14 @@ struct exynos_dvfs_info {
bool (*need_apll_change)(unsigned int, unsigned int);
 };
 
+#ifdef CONFIG_ARM_EXYNOS3250_CPUFREQ
+extern int exynos3250_cpufreq_init(struct exynos_dvfs_info *);
+#else
+static inline int exynos3250_cpufreq_init(struct exynos_dvfs_info *info)
+{
+   return -EOPNOTSUPP;
+}
+#endif
 #ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
 extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
 #else
diff --git a/drivers/cpufreq/exynos3250-cpufreq.c 
b/drivers/cpufreq/exynos3250-cpufreq.c
new file mode 100644
index 000..71f72b8
--- /dev/null
+++ b/drivers/cpufreq/exynos3250-cpufreq.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS3250 - CPU frequency scaling support
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "exynos-cpufreq.h"
+
+static struct clk *cpu_clk;
+static struct clk *mout_core;
+static struct clk *mout_mpll;
+static struct clk *mout_apll;
+
+static unsigned int exynos3250_volt_table[] = {
+   105, 105, 100, 95, 90,
+   90,   90,  90, 90, 90,
+};
+
+static struct cpufreq_frequency_table exynos3250_freq_table[] = {
+   {0, L0, 1000 * 1000},
+   

[PATCH 0/2] Support cpufreq driver for Exynos3250

2014-04-17 Thread Chanwoo Choi
This patchset support cpufreq driver for Exynos3250 which uses the Cortex-A7
dual cores and has a target speed of 1.0 GHz and code clean using dev_err/info
instead of pr_err/info function.

This patchset has a dependency on following patchset[1] to support Exynos3250:
[1] https://lkml.org/lkml/2014/4/17/669

Chanwoo Choi (2):
  cpufreq: exynos: Use dev_err/info function instead of pr_err/info
  cpufreq: exynos: Add new Exynos3250 cpufreq driver

 drivers/cpufreq/Kconfig.arm  |  11 +++
 drivers/cpufreq/Makefile |   1 +
 drivers/cpufreq/exynos-cpufreq.c |  25 +++---
 drivers/cpufreq/exynos-cpufreq.h |  18 
 drivers/cpufreq/exynos3250-cpufreq.c | 158 +++
 5 files changed, 203 insertions(+), 10 deletions(-)
 create mode 100644 drivers/cpufreq/exynos3250-cpufreq.c

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


[PATCHv3 7/7] ARM: dts: Add device tree sources for Exynos3250

2014-04-17 Thread Chanwoo Choi
From: Tomasz Figa 

This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:

- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus
- sysram node for SYSRAM memory mapping
- pmu node for PMU memory mapping

Signed-off-by: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Kyungmin Park 
Signed-off-by: Inki Dae 
Signed-off-by: Hyunhee Kim 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Ben Dooks 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Russell King 
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 ++
 arch/arm/boot/dts/exynos3250.dtsi | 427 ++
 2 files changed, 904 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi

diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as 
device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+/ {
+   pinctrl@1140 {
+   gpa0: gpa0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpa1: gpa1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpb: gpb {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc0: gpc0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc1: gpc1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpd0: gpd0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpd1: gpd1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   uart0_data: uart0-data {
+   samsung,pins = "gpa0-0", "gpa0-1";
+   samsung,pin-function = <0x2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart0_fctl: uart0-fctl {
+   samsung,pins = "gpa0-2", "gpa0-3";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart1_data: uart1-data {
+   samsung,pins = "gpa0-4", "gpa0-5";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart1_fctl: uart1-fctl {
+   samsung,pins = "gpa0-6", "gpa0-7";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   i2c2_bus: i2c2-bus {
+   samsung,pins = "gpa0-6", "gpa0-7";
+   samsung,pin-function = <3>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+
+   i2c3_bus: i2c3-bus {
+

[PATCHv3 6/7] dt-bindings: add documentation for Exynos3250 clock controller

2014-04-17 Thread Chanwoo Choi
The Exynos3250 clocks are statically listed and registered using the
Samsung specific common clock helper functions. Both device tree based
clock lookup and clkdev based clock lookups are supported.

Cc: Mike Turquette 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Randy Dunlap 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Tomasz Figa 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/clock/exynos3250-clock.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
new file mode 100644
index 000..aadc9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -0,0 +1,41 @@
+* Samsung Exynos3250 Clock Controller
+
+The Exynos3250 clock controller generates and supplies clock to various
+controllers within the Exynos3250 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos3250.h header and can be used in device
+tree sources.
+
+Example 1: An example of a clock controller node is listed below.
+
+   cmu: clock-controller@1003 {
+   compatible = "samsung,exynos3250-cmu";
+   reg = <0x1003 0x2>;
+   #clock-cells = <1>;
+   };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+  controller. Refer to the standard clock bindings for information
+  about 'clocks' and 'clock-names' property.
+
+   serial@1380 {
+   compatible = "samsung,exynos4210-uart";
+   reg = <0x1380 0x100>;
+   interrupts = <0 109 0>;
+   clocks = <&cmu CLK_UART0>, <&cmu CLK_SCLK_UART0>;
+   clock-names = "uart", "clk_uart_baud0";
+   };
-- 
1.8.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


[PATCHv3 5/7] clk: samsung: exynos3250: Add clocks using common clock framework

2014-04-17 Thread Chanwoo Choi
From: Tomasz Figa 

This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7
using common clock framework. The CMU (Clock Management Unit) of Exynos3250
control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses,
and function clocks for individual IPs.

The CMU of Exynos3250 includes following clock doamins:
- CPU block for Cortex-A7 MPCore processor
- LEFTBUS/RIGHTBUS block
- TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR

Cc: Mike Turquette 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Signed-off-by: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hyunhee Kim 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Inki Dae 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Karol Wrona 
Signed-off-by: YoungJun Cho 
Signed-off-by: Kyungmin Park 
---
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 +++
 3 files changed, 1042 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..d120797 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o
+obj-$(CONFIG_SOC_EXYNOS3250)   += clk-exynos3250.o
 obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-exynos3250.c 
b/drivers/clk/samsung/clk-exynos3250.c
new file mode 100644
index 000..0574a76
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -0,0 +1,785 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * 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.
+ *
+ * Common Clock Framework support for Exynos3250 SoC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+#include "clk-pll.h"
+
+#define SRC_LEFTBUS0x4200
+#define DIV_LEFTBUS0x4500
+#define GATE_IP_LEFTBUS0x4800
+#define SRC_RIGHTBUS   0x8200
+#define DIV_RIGHTBUS   0x8500
+#define GATE_IP_RIGHTBUS   0x8800
+#define GATE_IP_PERIR  0x8960
+#define MPLL_LOCK  0xc010
+#define MPLL_CON0  0xc110
+#define VPLL_LOCK  0xc020
+#define VPLL_CON0  0xc120
+#define UPLL_LOCK  0xc030
+#define UPLL_CON0  0xc130
+#define SRC_TOP0   0xc210
+#define SRC_TOP1   0xc214
+#define SRC_CAM0xc220
+#define SRC_MFC0xc228
+#define SRC_G3D0xc22c
+#define SRC_LCD0xc234
+#define SRC_ISP0xc238
+#define SRC_FSYS   0xc240
+#define SRC_PERIL0 0xc250
+#define SRC_PERIL1 0xc254
+#define SRC_MASK_TOP   0xc310
+#define SRC_MASK_CAM   0xc320
+#define SRC_MASK_LCD   0xc334
+#define SRC_MASK_ISP   0xc338
+#define SRC_MASK_FSYS  0xc340
+#define SRC_MASK_PERIL00xc350
+#define SRC_MASK_PERIL10xc354
+#define DIV_TOP0xc510
+#define DIV_CAM0xc520
+#define DIV_MFC0xc528
+#define DIV_G3D0xc52c
+#define DIV_LCD0xc534
+#define DIV_ISP0xc538
+#define DIV_FSYS0  0xc540
+#define DIV_FSYS1  0xc544
+#define DIV_FSYS2  0xc548
+#define DIV_PERIL0 0xc550
+#define DIV_PERIL1 0xc554
+#define DIV_PERIL3 0xc55c
+#define DIV_PERIL4 0xc560
+#define DIV_PERIL5 0xc564
+#define DIV_CAM1   0xc568
+#define CLKDIV2_RATIO  0xc580
+#define GATE_SCLK_CAM  0xc820
+#define GATE_SCLK_MFC  0xc828
+#define GATE_SCLK_G3D  0xc82c
+#define GATE_SCLK_LCD  0xc834
+#define GATE_SCLK_ISP_TOP  0xc838
+#define GATE_SCLK_FSYS 0xc840
+#define GATE_SCLK_PERIL0xc850
+#define GATE_IP_CAM0xc920
+#define GATE_IP_MFC0xc928
+#define GATE_IP_G3D0xc92c
+#define GATE_IP_LCD0xc934
+#define GATE_IP_ISP0xc938
+#define GATE_IP_FSYS   0xc940
+#define GATE_IP_PERIL  0xc950
+#define GATE_BLOCK 0xc970
+#define APLL_LOCK  0x14000
+#define APLL_CON0  0x14100
+#define SRC_CPU0x14200
+#define DIV_CPU0   0x14

[PATCHv3 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7

2014-04-17 Thread Chanwoo Choi
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.

Cc: Arnd Bergmann 
Cc: Marc Zynigier 
Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/hotplug.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
 
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
+* Prepare the CPU for shutting down. The required sequence of
+* operations depends on core type. CPUID part number can be used to
+* determine the right way.
 */
-   asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
-   if ((primary_part & 0xfff0) == 0xc0f0)
+   primary_part = read_cpuid_part_number();
+
+   switch (primary_part) {
+   case ARM_CPU_PART_CORTEX_A7:
+   case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
-   else
+   break;
+   default:
cpu_enter_lowpower_a9();
+   break;
+   }
 
platform_do_lowpower(cpu, &spurious);
 
-- 
1.8.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


[PATCHv3 2/7] ARM: EXYNOS: Support secondary CPU boot of Exynos4212

2014-04-17 Thread Chanwoo Choi
From: Kyungmin Park 

This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.

Signed-off-by: Kyungmin Park 
Signed-off-by: Chanwoo Choi 
---
 arch/arm/mach-exynos/firmware.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
 
 #include 
 
+#include 
+
 #include "smc.h"
 
 static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
 
 static int exynos_cpu_boot(int cpu)
 {
+   /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+   if (soc_is_exynos4212())
+   cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
 }
 
 static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
 {
-   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+   if (!soc_is_exynos4212())
+   boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
return 0;
-- 
1.8.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


[PATCHv3 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-17 Thread Chanwoo Choi
This patch fix the offset of CPU boot address and don't need to send smc call
of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
WFE in secure mode.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/firmware.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..386d01d 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -31,11 +31,17 @@ static int exynos_do_idle(void)
 static int exynos_cpu_boot(int cpu)
 {
/*
+* Exynos3250 doesn't need to send smc command for secondary CPU boot
+* because Exynos3250 removes WFE in secure mode.
+*/
+   if (soc_is_exynos3250())
+   return 0;
+   /*
 * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
 * But, Exynos4212 has only one secondary CPU so second parameter
 * isn't used for informing secure firmware about CPU id.
 */
-   if (soc_is_exynos4212())
+   else if (soc_is_exynos4212())
cpu = 0;
 
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
@@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
boot_addr)
 {
void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
 
-   if (!soc_is_exynos4212())
+   if (!soc_is_exynos4212() && !soc_is_exynos3250())
boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
-- 
1.8.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


[PATCHv3 1/7] ARM: EXYNOS: Add Exynos3250 SoC ID

2014-04-17 Thread Chanwoo Choi
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7
dual cores and has a target speed of 1.0GHz.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/Kconfig | 22 ++
 arch/arm/mach-exynos/exynos.c|  2 ++
 arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
 3 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
 
 menu "SAMSUNG EXYNOS SoCs Support"
 
+config ARCH_EXYNOS3
+   bool "SAMSUNG EXYNOS3"
+   select ARM_AMBA
+   select CLKSRC_OF
+   select HAVE_ARM_SCU if SMP
+   select HAVE_SMP
+   select PINCTRL
+   select PM_GENERIC_DOMAINS if PM_RUNTIME
+   help
+ Samsung EXYNOS3 SoCs based systems
+
 config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
 
 comment "EXYNOS SoCs"
 
+config SOC_EXYNOS3250
+   bool "SAMSUNG EXYNOS3250"
+   default y
+   depends on ARCH_EXYNOS3
+   select ARCH_HAS_BANDGAP
+   select ARM_CPU_SUSPEND if PM
+   select PINCTRL_EXYNOS
+   select SAMSUNG_DMADEV
+   help
+ Enable EXYNOS3250 CPU support
+
 config CPU_EXYNOS4210
bool "SAMSUNG EXYNOS4210"
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6a5fe18..e7dc6fd 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -346,6 +346,8 @@ static void __init exynos_dt_machine_init(void)
 }
 
 static char const *exynos_dt_compat[] __initconst = {
+   "samsung,exynos3",
+   "samsung,exynos3250",
"samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h 
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
 #define S5PV210_CPU_ID 0x4311
 #define S5PV210_CPU_MASK   0xF000
 
+#define EXYNOS3250_SOC_ID   0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
 #define EXYNOS4210_CPU_ID  0x4321
 #define EXYNOS4212_CPU_ID  0x4322
 #define EXYNOS4412_CPU_ID  0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
 IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
 IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
 IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
 IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, 
EXYNOS5_SOC_MASK)
 # define soc_is_s5pv210()  0
 #endif
 
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
+
 #if defined(CONFIG_CPU_EXYNOS4210)
 # define soc_is_exynos4210()   is_samsung_exynos4210()
 #else
-- 
1.8.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


[PATCHv3 0/7] Support new Exynos3250 SoC based on Cortex-A7 dual core

2014-04-17 Thread Chanwoo Choi
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core.
Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor
for Smartphone. It is desigend with the 28nm low-power high-K metal gate process
and provides the best performance features.

This patchset include some patches such as:
- Support secondary CPU of Exynos3250 (cpu up/down)
- Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba
- Support the clock control for Exynos3250 using common clk framework

This patchset is based on following git repo/branch.
- git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
- branch   : for-next (Linux 3.15-rc1)

Additional patch description about static memory mapping:
This patchset must need to map memory mapping about SYSRAM/PMU for CPU UP/DOWN.
So, this patchset need to merge following patchset to remove static memory
mapping for SYSRAM[1] / PMU ([2] or [3]).

[1] http://www.spinics.net/lists/arm-kernel/msg323011.html
[2] https://lkml.org/lkml/2014/4/2/48
[3] http://www.spinics.net/lists/arm-kernel/msg316013.html

And,
The pinctrl patch for Exynos3250 was posted as separated patch[4].
[4] https://lkml.org/lkml/2014/4/13/156

Changes from v2:
- Remove static memory mapping about SYSRAM/PMU such as following patches:
  ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
  ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
- Add description for secondary CPU boot of Exynos4212/Exynos3250
- Fix description in exynos_cpu_die() to remove particular SoC series
- Fix minor coding style
- Add documentation for Exynos3250 clock controller

Changes from v1:
- Add new "samsung,exynos3" compatible name
- Add comment about exynos_cpu_boot in Exynos4212
- Remove unnecessary 'goto' statement in firmware.c
- Use read_cpuid_part_number() function instead of assembler directly
- Post separated pinctrl patch from this patchset
  : https://lkml.org/lkml/2014/4/13/156
- Remove unused pmu interrupts due to Exynos3250 dual-core
- Cosolidate all the patches related to exynos3250.dtsi into one patch
- Fix gic compatible name to "cortex-a15-gic" because Cortex-A7 GIC is same
- Add sign-off of sender to all this patches
- Fix minor typo

Chanwoo Choi (4):
  ARM: EXYNOS: Add Exynos3250 SoC ID
  ARM: EXYNOS: Support secondary CPU boot of Exynos3250
  ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
  dt-bindings: add documentation for Exynos3250 clock controller

Kyungmin Park (1):
  ARM: EXYNOS: Support secondary CPU boot of Exynos4212

Tomasz Figa (2):
  clk: samsung: exynos3250: Add clocks using common clock framework
  ARM: dts: Add device tree sources for Exynos3250

 .../devicetree/bindings/clock/exynos3250-clock.txt |  41 ++
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi  | 477 +
 arch/arm/boot/dts/exynos3250.dtsi  | 427 +++
 arch/arm/mach-exynos/Kconfig   |  22 +
 arch/arm/mach-exynos/exynos.c  |   2 +
 arch/arm/mach-exynos/firmware.c|  21 +-
 arch/arm/mach-exynos/hotplug.c |  19 +-
 arch/arm/plat-samsung/include/plat/cpu.h   |  10 +
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 +++
 11 files changed, 2053 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

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


Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

2014-04-17 Thread Russell King - ARM Linux
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
> +static int exynos_drm_add_blocker(struct device *dev, void *data)
> +{
> + struct device_driver *drv = data;
> +
> + if (!platform_bus_type.match(dev, drv))
> + return 0;
> +
> + device_lock(dev);
> + if (!dev->driver)
> + exynos_drm_dev_busy(dev);
> + device_unlock(dev);
> +
> + return 0;
> +}
> +
> +static void exynos_drm_init_blockers(struct device_driver *drv)
> +{
> + bus_for_each_dev(&platform_bus_type, NULL, drv, exynos_drm_add_blocker);
> +}

This feels very wrong to be dumping the above code into every driver which
wants to make use of some kind of componentised support.

You also appear to need to know the struct device_driver's for every
component.  While that may work for exynos, it doesn't work elsewhere
where the various components of the system are very real separate
kernel modules - for example, a separate I2C driver such as the TDA998x
case I mentioned in my first reply.

I can't see how your solution would be usable in that circumstance.

The third issue I have is that you're still needing to have internal
exynos sub-device management - you're having to add the individual
devices to some kind of list, array or static data, and during DRM
probe you're having to then walk these lists/arrays/static data to
locate these sub-devices and finish each of their individual
initialisations.  So you're ending up with a two-tier initialisation.

That's not particularly good because it means you're exposed to
problems where the state is different between two initialisations -
when the device is recreated, your component attempts to re-finalise
the initialisation a second time.  It wouldn't take much for a field
to be assumed to be zero at init time somewhere for a bug to creep
in.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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 RFC 3/3] drm/exynos: use pending_components for components tracking

2014-04-17 Thread Russell King - ARM Linux
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
> +out:
> + if (ret != -EPROBE_DEFER)
> + exynos_drm_dev_ready(&pdev->dev);

So we end up with everyone needing a "ready" call in each sub-driver
back into the main driver... this makes it impossible to write a
generic subcomponent driver which is not tied in any way to the
main driver.

That is quite some restriction, and would prevent, for example, the
TDA998x driver being used both with Armada DRM, tilcdc and any other
driver.

So, while your solution may work for exynos, it's not suitable for
general use.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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


[RESEND PATCH 0/7] Add cros_ec changes for newer boards

2014-04-17 Thread Doug Anderson
This series adds the most critical cros_ec changes for newer boards
using cros_ec.  Specifically:
* Fixes timing/locking issues with the previously upstreamed (but
  never used upstream) cros_ec_spi driver.
* Updates the cros_ec header file to the latest version which allows
  us to use newer EC features like i2c tunneling.
* Adds an i2c tunnel driver to allow communication to the EC's i2c
  devices.

This _doesn't_ get the EC driver fully up to speed with what's in the
current Chromium OS trees.  There are a whole slew of cleanup patches
there, an addition of an LPC transport mode, and exports of functions
to userspace.  Once these patches land and we have functionality we
can continue to pick more cleanup patches.


Bill Richardson (1):
  mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

David Hendricks (1):
  mfd: cros_ec: spi: calculate delay between transfers correctly

Doug Anderson (5):
  mfd: cros_ec: spi: Add mutex to cros_ec_spi
  mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
  mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
  i2c: ChromeOS EC tunnel driver
  ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

 .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt |   36 +
 arch/arm/boot/dts/tegra124-venice2.dts |   27 +
 drivers/i2c/busses/Kconfig |9 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-cros-ec-tunnel.c|  304 ++
 drivers/mfd/cros_ec.c  |7 +-
 drivers/mfd/cros_ec_spi.c  |   67 +-
 include/linux/mfd/cros_ec.h|4 +-
 include/linux/mfd/cros_ec_commands.h   | 1128 ++--
 9 files changed, 1491 insertions(+), 92 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
 create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c

-- 
1.9.1.423.g4596e3a

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


[RESEND PATCH 6/7] i2c: ChromeOS EC tunnel driver

2014-04-17 Thread Doug Anderson
On ARM Chromebooks we have a few devices that are accessed by both the
AP (the main "Application Processor") and the EC (the Embedded
Controller).  These are:
* The battery (sbs-battery).
* The power management unit tps65090.

On the original Samsung ARM Chromebook these devices were on an I2C
bus that was shared between the AP and the EC and arbitrated using
some extranal GPIOs (see i2c-arb-gpio-challenge).

The original arbitration scheme worked well enough but had some
downsides:
* It was nonstandard (not using standard I2C multimaster)
* It only worked if the EC-AP communication was I2C
* It was relatively hard to debug problems (hard to tell if i2c issues
  were caused by the EC, the AP, or some device on the bus).

On the HP Chromebook 11 the design was changed to:
* The AP/EC comms were still i2c, but the battery/tps65090 were no
  longer on the bus used for AP/EC communication.  The battery was
  exposed to the AP through a limited i2c tunnel and tps65090 was
  exposed to the AP through a custom Linux driver.

On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
* The AP/EC comms are now using SPI for faster speeds.
* The EC's i2c bus is exposed to the AP through a full i2c tunnel.

The upstream "tegra124-venice2" uses the same scheme as the Samsung
ARM Chromebook 2, though it has a different set of components on the
other side of the bus.

This driver supports the scheme used by the Samsung ARM Chromebook 2.
Future patches to this driver could add support for the battery tunnel
on the HP Chromebook 11 (and perhaps could even be used to access
tps65090 on the HP Chromebook 11 instead of using a special driver,
but I haven't researched that enough).

Signed-off-by: Vincent Palatin 
Signed-off-by: Simon Glass 
Signed-off-by: Doug Anderson 
Tested-by: Andrew Bresticker 
---
 .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt |  36 +++
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-cros-ec-tunnel.c| 304 +
 drivers/mfd/cros_ec.c  |   5 +
 5 files changed, 355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
 create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt 
b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
new file mode 100644
index 000..30776bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
@@ -0,0 +1,36 @@
+I2C bus that tunnels through the ChromeOS EC (cros-ec)
+==
+On some ChromeOS board designs we've got a connection to the EC (embedded
+controller) but no direct connection to some devices on the other side of
+the EC (like a battery and PMIC).  To get access to those devices we need
+to tunnel our i2c commands through the EC.
+
+The node for this device should be under a cros-ec node like google,cros-ec-spi
+or google,cros-ec-i2c.
+
+
+Required properties:
+- compatible: google,cros-ec-i2c-tunnel
+- google,remote-bus: The EC bus we'd like to talk to.
+
+
+Example:
+   cros-ec@0 {
+   compatible = "google,cros-ec-spi";
+
+   ...
+
+   i2c-tunnel {
+   compatible = "google,cros-ec-i2c-tunnel";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   google,remote-bus = <0>;
+
+   battery: sbs-battery@b {
+   compatible = "sbs,sbs-battery";
+   reg = <0xb>;
+   sbs,poll-retry-count = <1>;
+   };
+   };
+   }
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c94db1c..9a0a6cc 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -993,6 +993,15 @@ config I2C_SIBYTE
help
  Supports the SiByte SOC on-chip I2C interfaces (2 channels).
 
+config I2C_CROS_EC_TUNNEL
+   tristate "ChromeOS EC tunnel I2C bus"
+   depends on MFD_CROS_EC
+   help
+ If you say yes here you get an I2C bus that will tunnel i2c commands
+ through to the other side of the ChromeOS EC to the i2c bus
+ connected there. This will work whatever the interface used to
+ talk to the EC (SPI, I2C or LPC).
+
 config SCx200_I2C
tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)"
depends on SCx200_GPIO
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 18d18ff..e110ca9 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_I2C_VIPERBOARD)  += i2c-viperboard.o
 # Other I2C/SMBus bus drivers
 obj-$(CONFIG_I2C_ACORN)+= i2c-acorn.o
 obj-$(CONFIG_I2C_BCM_KONA) += i2c-bcm-kona

[PATCH 3/7] mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable

2014-04-17 Thread Doug Anderson
The cros_ec_spi transfer had two problems with its timeout code:

1. It looked at the timeout even in the case that it found valid data.
2. If the cros_ec_spi code got switched out for a while, it's possible
   it could get a timeout after a single loop.  Let's be paranoid and
   make sure we do one last transfer after the timeout expires.

Signed-off-by: Doug Anderson 
---
 drivers/mfd/cros_ec_spi.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index a2a605d..4f863c3 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -113,7 +113,9 @@ static int cros_ec_spi_receive_response(struct 
cros_ec_device *ec_dev,
 
/* Receive data until we see the header byte */
deadline = jiffies + msecs_to_jiffies(EC_MSG_DEADLINE_MS);
-   do {
+   while (true) {
+   unsigned long start_jiffies = jiffies;
+
memset(&trans, 0, sizeof(trans));
trans.cs_change = 1;
trans.rx_buf = ptr = ec_dev->din;
@@ -134,12 +136,19 @@ static int cros_ec_spi_receive_response(struct 
cros_ec_device *ec_dev,
break;
}
}
+   if (ptr != end)
+   break;
 
-   if (time_after(jiffies, deadline)) {
+   /*
+* Use the time at the start of the loop as a timeout.  This
+* gives us one last shot at getting the transfer and is useful
+* in case we got context switched out for a while.
+*/
+   if (time_after(start_jiffies, deadline)) {
dev_warn(ec_dev->dev, "EC failed to respond in time\n");
return -ETIMEDOUT;
}
-   } while (ptr == end);
+   }
 
/*
 * ptr now points to the header byte. Copy any valid data to the
-- 
1.9.1.423.g4596e3a

--
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] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

2014-04-17 Thread Doug Anderson
From: Bill Richardson 

This just updates include/linux/mfd/cros_ec_commands.h to match the
latest EC version (which is the One True Source for such things).  See


[dianders: took today's ToT version from the Chromium OS EC; deleted
references to cros_ec_dev and cros_ec_lpc since those aren't upstream
yet]

Signed-off-by: Bill Richardson 
Signed-off-by: Doug Anderson 
---
 drivers/mfd/cros_ec.c|2 +-
 include/linux/mfd/cros_ec.h  |4 +-
 include/linux/mfd/cros_ec_commands.h | 1128 +++---
 3 files changed, 1059 insertions(+), 75 deletions(-)

diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 783fe2e..c58ab96 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -30,7 +30,7 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
uint8_t *out;
int csum, i;
 
-   BUG_ON(msg->out_len > EC_HOST_PARAM_SIZE);
+   BUG_ON(msg->out_len > EC_PROTO2_MAX_PARAM_SIZE);
out = ec_dev->dout;
out[0] = EC_CMD_VERSION0 + msg->version;
out[1] = msg->cmd;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 032af7f..887ef4f 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -29,8 +29,8 @@ enum {
EC_MSG_RX_PROTO_BYTES   = 3,
 
/* Max length of messages */
-   EC_MSG_BYTES= EC_HOST_PARAM_SIZE + EC_MSG_TX_PROTO_BYTES,
-
+   EC_MSG_BYTES= EC_PROTO2_MAX_PARAM_SIZE +
+   EC_MSG_TX_PROTO_BYTES,
 };
 
 /**
diff --git a/include/linux/mfd/cros_ec_commands.h 
b/include/linux/mfd/cros_ec_commands.h
index 86fd069..7853a64 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -24,25 +24,12 @@
 #define __CROS_EC_COMMANDS_H
 
 /*
- * Protocol overview
+ * Current version of this protocol
  *
- * request:  CMD [ P0 P1 P2 ... Pn S ]
- * response: ERR [ P0 P1 P2 ... Pn S ]
- *
- * where the bytes are defined as follow :
- *  - CMD is the command code. (defined by EC_CMD_ constants)
- *  - ERR is the error code. (defined by EC_RES_ constants)
- *  - Px is the optional payload.
- *it is not sent if the error code is not success.
- *(defined by ec_params_ and ec_response_ structures)
- *  - S is the checksum which is the sum of all payload bytes.
- *
- * On LPC, CMD and ERR are sent/received at EC_LPC_ADDR_KERNEL|USER_CMD
- * and the payloads are sent/received at EC_LPC_ADDR_KERNEL|USER_PARAM.
- * On I2C, all bytes are sent serially in the same message.
+ * TODO(crosbug.com/p/11223): This is effectively useless; protocol is
+ * determined in other ways.  Remove this once the kernel code no longer
+ * depends on it.
  */
-
-/* Current version of this protocol */
 #define EC_PROTO_VERSION  0x0002
 
 /* Command version mask */
@@ -57,13 +44,19 @@
 #define EC_LPC_ADDR_HOST_CMD   0x204
 
 /* I/O addresses for host command args and params */
-#define EC_LPC_ADDR_HOST_ARGS  0x800
-#define EC_LPC_ADDR_HOST_PARAM 0x804
-#define EC_HOST_PARAM_SIZE 0x0fc  /* Size of param area in bytes */
-
-/* I/O addresses for host command params, old interface */
-#define EC_LPC_ADDR_OLD_PARAM  0x880
-#define EC_OLD_PARAM_SIZE  0x080  /* Size of param area in bytes */
+/* Protocol version 2 */
+#define EC_LPC_ADDR_HOST_ARGS0x800  /* And 0x801, 0x802, 0x803 */
+#define EC_LPC_ADDR_HOST_PARAM   0x804  /* For version 2 params; size is
+* EC_PROTO2_MAX_PARAM_SIZE */
+/* Protocol version 3 */
+#define EC_LPC_ADDR_HOST_PACKET  0x800  /* Offset of version 3 packet */
+#define EC_LPC_HOST_PACKET_SIZE  0x100  /* Max size of version 3 packet */
+
+/* The actual block is 0x800-0x8ff, but some BIOSes think it's 0x880-0x8ff
+ * and they tell the kernel that so we have to think of it as two parts. */
+#define EC_HOST_CMD_REGION00x800
+#define EC_HOST_CMD_REGION10x880
+#define EC_HOST_CMD_REGION_SIZE 0x80
 
 /* EC command register bit functions */
 #define EC_LPC_CMDR_DATA   (1 << 0)  /* Data ready for host to read */
@@ -79,18 +72,22 @@
 #define EC_MEMMAP_TEXT_MAX 8   /* Size of a string in the memory map */
 
 /* The offset address of each type of data in mapped memory. */
-#define EC_MEMMAP_TEMP_SENSOR  0x00 /* Temp sensors */
-#define EC_MEMMAP_FAN  0x10 /* Fan speeds */
-#define EC_MEMMAP_TEMP_SENSOR_B0x18 /* Temp sensors (second set) */
-#define EC_MEMMAP_ID   0x20 /* 'E' 'C' */
+#define EC_MEMMAP_TEMP_SENSOR  0x00 /* Temp sensors 0x00 - 0x0f */
+#define EC_MEMMAP_FAN  0x10 /* Fan speeds 0x10 - 0x17 */
+#define EC_MEMMAP_TEMP_SENSOR_B0x18 /* More temp sensors 0x18 - 0x1f */
+#define EC_MEMMAP_ID   0x20 /* 0x20 == 'E', 0x21 == 'C' */
 #define EC_MEMMAP_ID_VERSION   0x22 /* Version of data in 0x20 - 0x2f */
 #define EC_MEMMAP_THERMAL_VERSION  0x23

[PATCH 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

2014-04-17 Thread Doug Anderson
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.

Signed-off-by: Doug Anderson 
---
 arch/arm/boot/dts/tegra124-venice2.dts | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts 
b/arch/arm/boot/dts/tegra124-venice2.dts
index c17283c..df97d15 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -8,6 +8,7 @@
compatible = "nvidia,venice2", "nvidia,tegra124";
 
aliases {
+   i2c20 = "/spi@0,7000d400/cros-ec@0/i2c-tunnel";
rtc0 = "/i2c@0,7000d000/pmic@40";
rtc1 = "/rtc@0,7000e000";
};
@@ -813,6 +814,32 @@
 
google,cros-ec-spi-msg-delay = <2000>;
 
+   i2c-tunnel {
+   compatible = "google,cros-ec-i2c-tunnel";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   google,remote-bus = <0>;
+
+   charger: bq24735@9 {
+   compatible = "ti,bq24735";
+   reg = <0x9>;
+   interrupt-parent = <&gpio>;
+   interrupts = ;
+   ti,ac-detect-gpios = <&gpio
+   TEGRA_GPIO(J, 0)
+   GPIO_ACTIVE_HIGH>;
+   };
+
+   battery: sbs-battery@b {
+   compatible = "sbs,sbs-battery";
+   reg = <0xb>;
+   sbs,i2c-retry-count = <2>;
+   sbs,poll-retry-count = <1>;
+   };
+   };
+
cros-ec-keyb {
compatible = "google,cros-ec-keyb";
keypad,num-rows = <8>;
-- 
1.9.1.423.g4596e3a

--
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] mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms

2014-04-17 Thread Doug Anderson
We're adding i2c tunneling to the list of things that goes over
cros_ec.  i2c tunneling can be slooow, so increase our deadline to
100ms to account for that.

Signed-off-by: Doug Anderson 
---
 drivers/mfd/cros_ec_spi.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 4f863c3..0b8d328 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -39,14 +39,22 @@
 #define EC_MSG_PREAMBLE_COUNT  32
 
 /*
-  * We must get a response from the EC in 5ms. This is a very long
-  * time, but the flash write command can take 2-3ms. The EC command
-  * processing is currently not very fast (about 500us). We could
-  * look at speeding this up and making the flash write command a
-  * 'slow' command, requiring a GET_STATUS wait loop, like flash
-  * erase.
-  */
-#define EC_MSG_DEADLINE_MS 5
+ * Allow for a long time for the EC to respond.  We support i2c
+ * tunneling and support fairly long messages for the tunnel (249
+ * bytes long at the moment).  If we're talking to a 100 kHz device
+ * on the other end and need to transfer ~256 bytes, then we need:
+ *  10 us/bit * ~10 bits/byte * ~256 bytes = ~25ms
+ *
+ * We'll wait 4 times that to handle clock stretching and other
+ * paranoia.
+ *
+ * It's pretty unlikely that we'll really see a 249 byte tunnel in
+ * anything other than testing.  If this was more common we might
+ * consider having slow commands like this require a GET_STATUS
+ * wait loop.  The 'flash write' command would be another candidate
+ * for this, clocking in at 2-3ms.
+ */
+#define EC_MSG_DEADLINE_MS 100
 
 /*
   * Time between raising the SPI chip select (for the end of a
-- 
1.9.1.423.g4596e3a

--
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] mfd: cros_ec: spi: Add mutex to cros_ec_spi

2014-04-17 Thread Doug Anderson
The main transfer function for cros_ec_spi can be called by more than
one client at a time.  Make sure that those clients don't stomp on
each other by locking the bus for the duration of the transfer
function.

Signed-off-by: Doug Anderson 
---
 drivers/mfd/cros_ec_spi.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c185eb6..a2a605d 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -65,11 +65,13 @@
  * if no record
  * @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
  *  is sent when we want to turn off CS at the end of a transaction.
+ * @lock: mutex to ensure only one user of cros_ec_command_spi_xfer at a time
  */
 struct cros_ec_spi {
struct spi_device *spi;
s64 last_transfer_ns;
unsigned int end_of_msg_delay;
+   struct mutex lock;
 };
 
 static void debug_packet(struct device *dev, const char *name, u8 *ptr,
@@ -208,6 +210,13 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device 
*ec_dev,
int ret = 0, final_ret;
struct timespec ts;
 
+   /*
+* We have the shared ec_dev buffer plus we do lots of separate spi_sync
+* calls, so we need to make sure only one person is using this at a
+* time.
+*/
+   mutex_lock(&ec_spi->lock);
+
len = cros_ec_prepare_tx(ec_dev, ec_msg);
dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
 
@@ -260,7 +269,7 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device 
*ec_dev,
ret = final_ret;
if (ret < 0) {
dev_err(ec_dev->dev, "spi transfer failed: %d\n", ret);
-   return ret;
+   goto exit;
}
 
/* check response error code */
@@ -269,14 +278,16 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device 
*ec_dev,
dev_warn(ec_dev->dev, "command 0x%02x returned an error %d\n",
 ec_msg->cmd, ptr[0]);
debug_packet(ec_dev->dev, "in_err", ptr, len);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto exit;
}
len = ptr[1];
sum = ptr[0] + ptr[1];
if (len > ec_msg->in_len) {
dev_err(ec_dev->dev, "packet too long (%d bytes, expected %d)",
len, ec_msg->in_len);
-   return -ENOSPC;
+   ret = -ENOSPC;
+   goto exit;
}
 
/* copy response packet payload and compute checksum */
@@ -293,10 +304,14 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device 
*ec_dev,
dev_err(ec_dev->dev,
"bad packet checksum, expected %02x, got %02x\n",
sum, ptr[len + 2]);
-   return -EBADMSG;
+   ret = -EBADMSG;
+   goto exit;
}
 
-   return 0;
+   ret = 0;
+exit:
+   mutex_unlock(&ec_spi->lock);
+   return ret;
 }
 
 static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device 
*dev)
@@ -327,6 +342,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
if (ec_spi == NULL)
return -ENOMEM;
ec_spi->spi = spi;
+   mutex_init(&ec_spi->lock);
ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
if (!ec_dev)
return -ENOMEM;
-- 
1.9.1.423.g4596e3a

--
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] mfd: cros_ec: spi: calculate delay between transfers correctly

2014-04-17 Thread Doug Anderson
From: David Hendricks 

To avoid spamming the EC we calculate the time between the previous
transfer and the current transfer and force a delay if the time delta
is too small.

However, a small miscalculation causes the delay period to be
far too short. Most noticably this impacts commands with a long
turnaround time such as EC firmware reads and writes.

Signed-off-by: David Hendricks 
Signed-off-by: Doug Anderson 
---
 drivers/mfd/cros_ec_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 84af8d7..c185eb6 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -219,7 +219,7 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device 
*ec_dev,
ktime_get_ts(&ts);
delay = timespec_to_ns(&ts) - ec_spi->last_transfer_ns;
if (delay < EC_SPI_RECOVERY_TIME_NS)
-   ndelay(delay);
+   ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
}
 
/* Transmit phase - send our message */
-- 
1.9.1.423.g4596e3a

--
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: [rtc-linux] Re: [PATCH resend] mfd/rtc: s5m: Do not allocate RTC I2C dummy and regmap for unsupported chipsets

2014-04-17 Thread Alessandro Zummo
On Thu, 17 Apr 2014 09:08:47 +0100
Lee Jones  wrote:

> MFD changes look good to me. If Alessandro provides his Ack for the
> RTC adaptions I can setup an MFD-RTC branch for him to pull from in
> order to save conflicts at merge time.

 Hello,
   I do not keep an rtc git, so please add it to mfd
 or via another tree / next. The patch looks good to m.
 
 Acked-by: Alessandro Zummo 
  

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

--
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 3/5] mfd: tps65090: Stop caching most registers

2014-04-17 Thread Doug Anderson
Lee,

On Thu, Apr 17, 2014 at 4:00 AM, Lee Jones  wrote:
>> Nearly all of the registers in tps65090 combine control bits and
>> status bits.  Turn off caching of all registers except the select few
>> that can be cached.
>>
>> In order to avoid adding more duplicate #defines, we also move some
>> register offset definitions to the mfd driver (and resolve
>> inconsistent names).
>>
>> Signed-off-by: Doug Anderson 
>> ---
>> Changes in v3: None
>> Changes in v2:
>> - Leave cache on for the registers that can be cached.
>> - Move register offsets to mfd header file.
>>
>>  drivers/mfd/tps65090.c   | 27 ++-
>>  drivers/power/tps65090-charger.c | 11 ---
>>  include/linux/mfd/tps65090.h | 14 ++
>>  3 files changed, 28 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
>> index c3cddb4..1c3e6e2 100644
>> --- a/drivers/mfd/tps65090.c
>> +++ b/drivers/mfd/tps65090.c
>> @@ -32,14 +32,6 @@
>>  #define NUM_INT_REG 2
>>  #define TOTAL_NUM_REG 0x18
>>
>> -/* interrupt status registers */
>> -#define TPS65090_INT_STS 0x0
>> -#define TPS65090_INT_STS20x1
>> -
>> -/* interrupt mask registers */
>> -#define TPS65090_INT_MSK 0x2
>> -#define TPS65090_INT_MSK20x3
>> -
>>  #define TPS65090_INT1_MASK_VAC_STATUS_CHANGE 1
>>  #define TPS65090_INT1_MASK_VSYS_STATUS_CHANGE2
>>  #define TPS65090_INT1_MASK_BAT_STATUS_CHANGE 3
>> @@ -144,17 +136,26 @@ static struct regmap_irq_chip tps65090_irq_chip = {
>>   .irqs = tps65090_irqs,
>>   .num_irqs = ARRAY_SIZE(tps65090_irqs),
>>   .num_regs = NUM_INT_REG,
>> - .status_base = TPS65090_INT_STS,
>> - .mask_base = TPS65090_INT_MSK,
>> + .status_base = TPS65090_REG_INTR_STS,
>> + .mask_base = TPS65090_REG_INTR_MASK,
>>   .mask_invert = true,
>>  };
>>
>>  static bool is_volatile_reg(struct device *dev, unsigned int reg)
>>  {
>> - if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
>> - return true;
>> - else
>> + /* Nearly all registers have status bits mixed in, except a few */
>> + switch (reg) {
>> + case TPS65090_REG_INTR_MASK:
>> + case TPS65090_REG_INTR_MASK2:
>> + case TPS65090_REG_CG_CTRL0:
>> + case TPS65090_REG_CG_CTRL1:
>> + case TPS65090_REG_CG_CTRL2:
>> + case TPS65090_REG_CG_CTRL3:
>> + case TPS65090_REG_CG_CTRL4:
>> + case TPS65090_REG_CG_CTRL5:
>>   return false;
>> + }
>> + return true;
>>  }
>
> I'll not force the issue, but if you wanted to do this more succinctly
> you could also do:
>
>   case TPS65090_REG_INTR_MASK ... TPS65090_REG_INTR_MASK:
>   case TPS65090_REG_CG_CTRL0  ... TPS65090_REG_CG_CTRL5:
>
> or
>
>   if (reg >= TPS65090_REG_INTR_MASK && reg <= TPS65090_REG_CG_CTRL5)
>
> Ect.
>
> Otherwise patch looks fine:
>   Acked-by: Lee Jones 

If I need to spin the series for another reason I'll make that change.
 Otherwise I won't plan to spin.  Thanks for the review!

-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 v2 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

2014-04-17 Thread Marc Zyngier
On Wed, Apr 16 2014 at  5:33:31 am BST, Jungseok Lee  
wrote:
> This patch adds 4 levels of translation tables implementation for both
> HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4 levels
> guest can run on ARMv8 architecture as introducing this feature.

Just to be sure: have you tested it with asymetric configurations (4kB
host, 64kB guest, and the oposite configuration)?

> Signed-off-by: Jungseok Lee 
> Reviewed-by: Sungjinn Chung 
> ---
>  arch/arm/include/asm/kvm_mmu.h   |   10 +
>  arch/arm/kvm/mmu.c   |   88 
> +-
>  arch/arm64/include/asm/kvm_arm.h |   20 +
>  arch/arm64/include/asm/kvm_mmu.h |   10 +
>  4 files changed, 117 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 5c7aa3c..6f7906e 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -37,6 +37,11 @@
>   */
>  #define TRAMPOLINE_VAUL(CONFIG_VECTORS_BASE)
>  
> +/*
> + * NUM_OBJS depends on the number of page table translation levels
> + */
> +#define NUM_OBJS 2

I'm afraid this is way too generic. Use something along the lines of
MMU_CACHE_MIN_PAGES, that makes it obvious what we're talking about.

> +
>  #ifndef __ASSEMBLY__
>  
>  #include 
> @@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
>   clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));
>  }
>  
> +static inline void kvm_clean_pmd(pmd_t *pmd)
> +{
> + clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
> +}
> +
>  static inline void kvm_clean_pmd_entry(pmd_t *pmd)
>  {
>   clean_pmd_entry(pmd);
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 80bb1e6..7fc9e55 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -388,13 +388,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned 
> long start,
>   return 0;
>  }
>  
> +static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
> +unsigned long end, unsigned long pfn,
> +pgprot_t prot)
> +{
> + pud_t *pud;
> + pmd_t *pmd;
> + unsigned long addr, next;
> +
> + addr = start;
> + do {
> + pud = pud_offset(pgd, addr);
> +
> + if (pud_none_or_clear_bad(pud)) {
> + pmd = pmd_alloc_one(NULL, addr);
> + if (!pmd) {
> + kvm_err("Cannot allocate Hyp pmd\n");
> + return -ENOMEM;
> + }
> + pud_populate(NULL, pud, pmd);
> + get_page(virt_to_page(pud));
> + kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> + }
> +
> + next = pud_addr_end(addr, end);
> +
> + create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> + pfn += (next - addr) >> PAGE_SHIFT;
> + } while (addr = next, addr != end);
> +
> + return 0;
> +}
> +
>  static int __create_hyp_mappings(pgd_t *pgdp,
>unsigned long start, unsigned long end,
>unsigned long pfn, pgprot_t prot)
>  {
>   pgd_t *pgd;
>   pud_t *pud;
> - pmd_t *pmd;
>   unsigned long addr, next;
>   int err = 0;
>  
> @@ -403,22 +434,23 @@ static int __create_hyp_mappings(pgd_t *pgdp,
>   end = PAGE_ALIGN(end);
>   do {
>   pgd = pgdp + pgd_index(addr);
> - pud = pud_offset(pgd, addr);
>  
> - if (pud_none_or_clear_bad(pud)) {
> - pmd = pmd_alloc_one(NULL, addr);
> - if (!pmd) {
> - kvm_err("Cannot allocate Hyp pmd\n");
> + if (pgd_none(*pgd)) {
> + pud = pud_alloc_one(NULL, addr);
> + if (!pud) {
> + kvm_err("Cannot allocate Hyp pud\n");
>   err = -ENOMEM;
>   goto out;
>   }
> - pud_populate(NULL, pud, pmd);
> - get_page(virt_to_page(pud));
> - kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> + pgd_populate(NULL, pgd, pud);
> + get_page(virt_to_page(pgd));
> + kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
>   }
>  
>   next = pgd_addr_end(addr, end);
> - err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> +
> + err = create_hyp_pud_mappings(pgd, addr, next, pfn, prot);
> +
>   if (err)
>   goto out;
>   pfn += (next - addr) >> PAGE_SHIFT;
> @@ -563,6 +595,24 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
>   kvm->arch.pgd = NULL;
>  }
>  
> +static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache 
> *cache,
> +

[RFC PATCH v3 10/14] drm/panel: add S6E3FA0 driver

2014-04-17 Thread YoungJun Cho
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.

Changelog v2:
- Declares delay, size properties in probe routine instead of DT

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/panel/Kconfig |7 +
 drivers/gpu/drm/panel/Makefile|1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c |  547 +
 3 files changed, 555 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_S6E3FA0
+   tristate "S6E3FA0 DSI command mode panel"
+   depends on DRM && DRM_PANEL
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c 
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..4014951
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,547 @@
+/*
+ * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho 
+ *
+ * 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 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+struct s6e3fa0 {
+   struct device   *dev;
+   struct drm_panelpanel;
+
+   struct regulator_bulk_data  supplies[2];
+   struct gpio_desc*reset_gpio;
+   struct gpio_desc*det_gpio;
+   struct gpio_desc*te_gpio;
+   struct videomodevm;
+
+   unsigned intpower_on_delay;
+   unsigned intreset_delay;
+   unsigned intinit_delay;
+   unsigned intwidth_mm;
+   unsigned intheight_mm;
+
+   unsigned char   id;
+   unsigned char   vddm;
+   unsigned intbrightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+   {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+   {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+   {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+   {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+   {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+   {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+   {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+   {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+   {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+   {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+   {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+   {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+   {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+   {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+   {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
+   {0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
+   {0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
+   {0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
+   {0x5a, 0x4e}, {0x5b, 0x4f}, {0x5c, 0x50}, {0x5d, 0x51}, {0x5e, 0x52},
+   {0x5f, 0x53}, {0x60, 0x54}, {0x61, 0x55}, {0x62, 0x56}, {0x63, 0x57},
+   {0x64, 0x58}, {0x65, 0x59}, {0x66, 0x5a}, {0x67, 0x5b}, {0x68, 0x5c},
+   {0x69, 0x5d}, {0x6a, 0x5e}, {0x6b, 0x5f}, {0x6c, 0x60}, {0x6d, 0x61},
+   {0x6e, 0x62}, {0x6f, 0x63}, {0x70, 0x64}, {0x71, 0x65}, {0x72, 0x66},
+   {0x73, 0x67}, {0x74, 0x68}, {0x75, 0x69}, {0x76, 0x6a}, {0x77, 0x6b},
+   {0x78, 0x6c}, {0x79, 0x6d}, {0x7a, 0x6e}, {0x7b, 0x6f}, {0x7c, 0x70},

[RFC PATCH v3 09/14] ARM: dts: s6e3fa0: add DT bindings

2014-04-17 Thread YoungJun Cho
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings, delays
and physical size.

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

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   46 
 1 file changed, 46 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..8aabeca
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,46 @@
+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-gpio: a GPIO spec for the reset pin
+  - det-gpio: a GPIO spec for the OLED detection pin
+  - te-gpio: a GPIO spec for the TE pin
+  - display-timings: timings for the connected panel as described by [1]
+
+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-gpio = <&gpy7 4 0>;
+   det-gpio = <&gpg0 6 0>;
+   te-gpio = <&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>;
+   };
+   };
+   };
-- 
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


[RFC PATCH v2 05/14] ARM: dts: samsung-fimd: add I80 specific properties

2014-04-17 Thread YoungJun Cho
In case of using CPU interface panel, the relevant registers should be set.
So this patch adds relevant dt bindings.

Changelog v2:
- Changes "samsung,sysreg-phandle" to "samsung,sysreg"

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 .../devicetree/bindings/video/samsung-fimd.txt |9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..6ea1adc 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -44,6 +44,15 @@ Optional Properties:
 - display-timings: timing settings for FIMD, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
+- samsung,sysreg: handle to syscon used to control the system registers
+- vidout-i80-ldi: boolean to support i80 interface instead of rgb one
+- cs-setup: clock cycles for the active period of address signal enable until
+   chip select is enable in i80 interface
+- wr-setup: clock cycles for the active period of CS signal enable until
+   write signal is enable in i80 interface
+- wr-act: clock cycles for the active period of CS enable in i80 interface
+- wr-hold: clock cycles for the active period of CS disable until write signal
+   is disable in i80 interface
 
 The device node can contain 'port' child nodes according to the bindings 
defined
 in [2]. The following are properties specific to those nodes:
-- 
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: [PATCHv3 2/2] iio: devicetree: Add DT binding documentation for Exynos3250 ADC

2014-04-17 Thread Chanwoo Choi
Hi Tomasz,

On 04/16/2014 08:49 PM, Tomasz Figa wrote:
> Hi Chanwoo,
> 
> On 16.04.2014 12:11, Chanwoo Choi wrote:
>> This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
>> special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
>>
>> Cc: Rob Herring 
>> Cc: Pawel Moll 
>> Cc: Mark Rutland 
>> Cc: Ian Campbell 
>> Cc: Kumar Gala 
>> Cc: Randy Dunlap 
>> Cc: Kukjin Kim 
>> Cc: Naveen Krishna Chatradhi 
>> Cc: Tomasz Figa 
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Kyungmin Park 
>> ---
>>   .../devicetree/bindings/arm/samsung/exynos-adc.txt   | 20 
>> 
>>   1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
>> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> index 5d49f2b..7532ec3 100644
>> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> @@ -14,6 +14,8 @@ Required properties:
>>   for exynos4412/5250 controllers.
>>   Must be "samsung,exynos-adc-v2" for
>>   future controllers.
>> +Must be "samsung,exynos-adc-v3" for
>> +for exynos3250 controllers.
> 
> I don't think adc-v3 is correct here. It looks like a normal V2 with 
> additional special clock input. Possibly "samsung,exynos3250-adc-v2" or 
> "samsung,exynos-adc-v2-sclk" would be better choices.

OK, I'll fix it with following compatible
- "samsung,exynos-adc-v2-sclk"

> 
>>   - reg:Contains ADC register address range (base address and
>>   length) and the address of the phy enable register.
>>   - interrupts: Contains the interrupt information for the timer. The
>> @@ -21,7 +23,11 @@ Required properties:
>>   the Samsung device uses.
>>   - #io-channel-cells = <1>; As ADC has multiple outputs
>>   - clocksFrom common clock binding: handle to adc clock.
>> +From common clock binding: handle to sclk_tsadc clock
>> +if using Exynos3250.
>>   - clock-namesFrom common clock binding: Shall be "adc".
>> +From common clock binding: Shall be "sclk_tsadc"
>> +if using Exynos3250.
>>   - vdd-supplyVDD input supply.
>>
>>   Note: child nodes can be added for auto probing from device tree.
>> @@ -41,6 +47,20 @@ adc: adc@12D1 {
>>   vdd-supply = <&buck5_reg>;
>>   };
>>
>> +If Exynos3250 uses ADC,
> 
> Please keep proper formatting:
> 
> Example: Node for ADC of Exynos3250 with additional special clock

Thanks, I'll fix it.

Best regards,
Chanwoo Choi
--
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 RFC 2/3] drivers/base: provide lightweight framework for componentized devices

2014-04-17 Thread Andrzej Hajda
Many subsystems (eg. DRM, ALSA) requires that multiple devices should
be composed into one superdevice. The superdevice cannot start until
all components are ready and it should stop before any of its components
becomes not-ready.
This framework provides a way to track readiness of all components with
minimal impact on the code of the drivers.
The superdevice provides pending_components structure and adds all components
to it, device drivers removes themselves from the list if they becomes ready.
If the list becomes empty callback is fired which causes superdevice to start.
Later if any components wants to become not-ready it adds again itself to the
list and callback is fired to stop superdevice.

Signed-off-by: Andrzej Hajda 
---
 drivers/base/Kconfig   |  3 ++
 drivers/base/Makefile  |  1 +
 drivers/base/pending_components.c  | 93 ++
 include/linux/pending_components.h | 30 
 4 files changed, 127 insertions(+)
 create mode 100644 drivers/base/pending_components.c
 create mode 100644 include/linux/pending_components.h

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index ec36e77..71ce050 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -278,4 +278,7 @@ config CMA_AREAS
 
 endif
 
+config PENDING_COMPONENTS
+   boolean
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e..3a51654 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o
 obj-$(CONFIG_REGMAP)   += regmap/
 obj-$(CONFIG_SOC_BUS) += soc.o
 obj-$(CONFIG_PINCTRL) += pinctrl.o
+obj-$(CONFIG_PENDING_COMPONENTS) += pending_components.o
 
 ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
 
diff --git a/drivers/base/pending_components.c 
b/drivers/base/pending_components.c
new file mode 100644
index 000..f15104e
--- /dev/null
+++ b/drivers/base/pending_components.c
@@ -0,0 +1,93 @@
+/*
+ * Lightweight framework for handling componentized devices.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Andrzej Hajda 
+ *
+ * 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.
+ *
+ * pending_components structure contains list of components which are not yet
+ * ready. Components can remove or add themselves from/to the list. If the list
+ * becomes empty/non-empty optional callback is fired.
+*/
+
+#include 
+#include 
+
+struct pending_components_node {
+   struct list_head list;
+   void *data;
+};
+
+int pending_components_insert(struct pending_components *set, void *item)
+{
+   struct pending_components_node *n;
+   int ret = 0;
+
+   mutex_lock(&set->lock);
+
+   list_for_each_entry(n, &set->list, list) {
+   if (n->data == item)
+   goto out;
+   }
+
+   n = kmalloc(sizeof(*n), GFP_KERNEL);
+   if (!n) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   n->data = item;
+   list_add_tail(&n->list, &set->list);
+   if (set->callback && set->list.next == set->list.prev)
+   ret = set->callback(set, false);
+
+out:
+   mutex_unlock(&set->lock);
+
+   return ret;
+}
+
+int pending_components_delete(struct pending_components *set, void *item)
+{
+   struct pending_components_node *n;
+   int ret = 0;
+
+   mutex_lock(&set->lock);
+
+   list_for_each_entry(n, &set->list, list) {
+   if (n->data == item) {
+   list_del(&n->list);
+   kfree(n);
+   if (set->callback && list_empty(&set->list))
+   ret = set->callback(set, true);
+   break;
+   }
+   }
+
+   mutex_unlock(&set->lock);
+
+   return ret;
+}
+
+void pending_components_set_callback(struct pending_components *set,
+pending_components_callback cb)
+{
+   mutex_lock(&set->lock);
+
+   set->callback = cb;
+
+   mutex_unlock(&set->lock);
+}
+
+void pending_components_cleanup(struct pending_components *set)
+{
+   struct pending_components_node *n, *tmp;
+
+   list_for_each_entry_safe(n, tmp, &set->list, list) {
+   list_del(&n->list);
+   kfree(n);
+   }
+}
diff --git a/include/linux/pending_components.h 
b/include/linux/pending_components.h
new file mode 100644
index 000..dd29616
--- /dev/null
+++ b/include/linux/pending_components.h
@@ -0,0 +1,30 @@
+#ifndef PENDING_COMPONENTS_H
+#define PENDING_COMPONENTS_H
+
+#include 
+#include 
+
+struct pending_components;
+
+typedef int (*pending_components_callback)(struct pending_components *set,
+  bool empty);
+
+struct pending_components {
+   struct mutex lock;
+   struct list_head list;
+   pending_compon

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

2014-04-17 Thread Andrzej Hajda
exynos_drm is composed from multiple devices which provides different
interfaces. To properly start/stop drm master device it should track
readiness of all its components. This patch uses pending_components
framework to perform this task.
On module initialization before component driver registration all devices
matching drivers are added to pending_components. Drivers during probe
are removed from the list unless deferred probe happens. When list becomes
empty callback is fired to start drm master. Later if any device adds itself
to the list callback is fired to stop drm master.

The core of the changes is in exynos_drm_drv.c. Driver modifications are
limited only to signal its readiness in probe and remove driver callbacks.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/Kconfig  |  1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c | 36 +++--
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 61 +++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  3 ++
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 41 +++
 drivers/gpu/drm/exynos/exynos_drm_fimc.c| 34 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c| 37 +++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 17 ++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 30 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 18 ++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 27 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c| 16 +---
 drivers/gpu/drm/exynos/exynos_hdmi.c| 53 +
 drivers/gpu/drm/exynos/exynos_mixer.c   | 13 --
 14 files changed, 278 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 5bf5bca..4ed8eb2 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -8,6 +8,7 @@ config DRM_EXYNOS
select FB_CFB_IMAGEBLIT
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
select VIDEOMODE_HELPERS
+   select PENDING_COMPONENTS
help
  Choose this option if you have a Samsung SoC EXYNOS chipset.
  If M is selected the module will be called exynosdrm.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 9385e96..24f5c98 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1240,29 +1240,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
if (!dp) {
-   dev_err(&pdev->dev, "no memory for device data\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto out;
}
 
dp->dev = &pdev->dev;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 
dp->video_info = exynos_dp_dt_parse_pdata(&pdev->dev);
-   if (IS_ERR(dp->video_info))
-   return PTR_ERR(dp->video_info);
+   if (IS_ERR(dp->video_info)) {
+   ret = PTR_ERR(dp->video_info);
+   goto out;
+   }
 
ret = exynos_dp_dt_parse_phydata(dp);
if (ret)
-   return ret;
+   goto out;
 
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
-   return ret;
+   goto out;
 
dp->clock = devm_clk_get(&pdev->dev, "dp");
if (IS_ERR(dp->clock)) {
dev_err(&pdev->dev, "failed to get clock\n");
-   return PTR_ERR(dp->clock);
+   ret = PTR_ERR(dp->clock);
+   goto out;
}
 
clk_prepare_enable(dp->clock);
@@ -1270,13 +1273,16 @@ static int exynos_dp_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
dp->reg_base = devm_ioremap_resource(&pdev->dev, res);
-   if (IS_ERR(dp->reg_base))
-   return PTR_ERR(dp->reg_base);
+   if (IS_ERR(dp->reg_base)) {
+   ret = PTR_ERR(dp->reg_base);
+   goto out;
+   }
 
dp->irq = platform_get_irq(pdev, 0);
if (dp->irq == -ENXIO) {
dev_err(&pdev->dev, "failed to get irq\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto out;
}
 
INIT_WORK(&dp->hotplug_work, exynos_dp_hotplug);
@@ -1289,7 +1295,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
"exynos-dp", dp);
if (ret) {
dev_err(&pdev->dev, "failed to request irq\n");
-   return ret;
+   goto out;
}
disable_irq(dp->irq);
 
@@ -1298,13 +1304,19 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, &exynos_dp_display);
exynos_drm_display_register(&exynos_dp_display);
 
-   return 0;
+out:
+   if (ret != -EPROBE_DE

[PATCH RFC 1/3] drm/exynos: refactor drm drivers registration code

2014-04-17 Thread Andrzej Hajda
The patch removes driver registration code based on preprocessor conditionals.
Instead it uses private linker section to create array of drm drivers.

Signed-off-by: Andrzej Hajda 
---
v2:
- minor fixes of compilation issues
---
 drivers/gpu/drm/exynos/Makefile |   2 +
 drivers/gpu/drm/exynos/exynos_dp_core.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm.lds.S |   9 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 203 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  30 ++--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|   2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   2 +-
 15 files changed, 68 insertions(+), 198 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm.lds.S

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 33ae365..c8190c1 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -22,4 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
 
+exynosdrm-y+= exynos_drm.lds
+
 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index aed533b..9385e96 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1340,7 +1340,7 @@ static const struct of_device_id exynos_dp_match[] = {
{},
 };
 
-struct platform_driver dp_driver = {
+EXYNOS_DRM_DRV(dp_driver) = {
.probe  = exynos_dp_probe,
.remove = exynos_dp_remove,
.driver = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm.lds.S 
b/drivers/gpu/drm/exynos/exynos_drm.lds.S
new file mode 100644
index 000..fd37dc1
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm.lds.S
@@ -0,0 +1,9 @@
+SECTIONS
+{
+   .data : {
+   . = ALIGN(8);
+   exynos_drm_drivers = .;
+   *(exynos_drm_drivers)
+   *(exynos_drm_drivers_last)
+   }
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2d27ba2..5067b32 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -430,7 +430,7 @@ static const struct dev_pm_ops exynos_drm_pm_ops = {
exynos_drm_runtime_resume, NULL)
 };
 
-static struct platform_driver exynos_drm_platform_driver = {
+EXYNOS_DRM_DRV_LAST(exynos_drm_drv) = {
.probe  = exynos_drm_platform_probe,
.remove = exynos_drm_platform_remove,
.driver = {
@@ -440,197 +440,64 @@ static struct platform_driver exynos_drm_platform_driver 
= {
},
 };
 
-static int __init exynos_drm_init(void)
+static int exynos_platform_device_drm_register(void)
 {
-   int ret;
-
-#ifdef CONFIG_DRM_EXYNOS_DP
-   ret = platform_driver_register(&dp_driver);
-   if (ret < 0)
-   goto out_dp;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DSI
-   ret = platform_driver_register(&dsi_driver);
-   if (ret < 0)
-   goto out_dsi;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_FIMD
-   ret = platform_driver_register(&fimd_driver);
-   if (ret < 0)
-   goto out_fimd;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_HDMI
-   ret = platform_driver_register(&hdmi_driver);
-   if (ret < 0)
-   goto out_hdmi;
-   ret = platform_driver_register(&mixer_driver);
-   if (ret < 0)
-   goto out_mixer;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_VIDI
-   ret = platform_driver_register(&vidi_driver);
-   if (ret < 0)
-   goto out_vidi;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_G2D
-   ret = platform_driver_register(&g2d_driver);
-   if (ret < 0)
-   goto out_g2d;
-#endif
+   exynos_drm_pdev = platform_device_register_simple("exynos-drm", -1,
+ NULL, 0);
+   if (IS_ERR(exynos_drm_pdev))
+   return PTR_ERR(exynos_drm_pdev);
 
-#ifdef CONFIG_DRM_EXYNOS_FIMC
-   ret = platform_driver_register(&fimc_driver);
-   if (ret < 0)
-   goto out_fimc;
-#endif
+   return 0;
+}
 
-#ifdef CONFIG_DRM_EXYNOS_ROTATOR
-   ret = platform_driver_register(&rotator_driver);
-   if (ret < 0)
-   goto out_rotator;
-#endif
+static void exynos_platform_device_drm_unregister(void)
+{
+ 

[PATCH RFC 0/3] drm/exynos: refactoring drm initialization/cleanup code

2014-04-17 Thread Andrzej Hajda
Hi,

The patchset presents alternative approach to superdevice DT node
and components framework. It also refactors Exynos DRM device initialization.

The first patch uses linker sections to get rid of ifdef macros, it is not
essential for the rest of patchset but it makes code more readable.
Similar approach is used by irqchip, clks and clk_sources.
Any comments are welcome, especially regarding linker script usage in drivers.

The second patch proposes pending_components framework - lightweight alternative
for componentized devices.
Details are described in the patch description. But as it is an alternative for
component framework I would like to show differences:
- it is simpler and more straightforward,
- it requires only minimal changes to component drivers,
- only one callback to implement,
- no unwinding, component framework in case of error removes all already added
  components and unbinds all already bound components,
- it is instantiated per superdevice, component framework uses global list,
  the disadvantage is that we create dependency between components and
  the superdevice, but in case of Exynos DRM the dependency is present already,
- no two stage component initialization: probe, bind,
- it is more lightweight,
- it clearly separates device probing order issue from registering interfaces
  provided by the device.

The third patch implements pending_components framework in Exynos DRM.
Details are in patch description.

The patchset is based on exynos-drm-next branch.

Regards
Andrzej


Andrzej Hajda (3):
  drm/exynos: refactor drm drivers registration code
  drivers/base: provide lightweight framework for componentized devices
  drm/exynos: use pending_components for components tracking

 drivers/base/Kconfig|   3 +
 drivers/base/Makefile   |   1 +
 drivers/base/pending_components.c   |  93 +++
 drivers/gpu/drm/exynos/Kconfig  |   1 +
 drivers/gpu/drm/exynos/Makefile |   2 +
 drivers/gpu/drm/exynos/exynos_dp_core.c |  38 +++--
 drivers/gpu/drm/exynos/exynos_drm.lds.S |   9 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 250 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  33 ++--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  43 +++--
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  36 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  39 +++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  19 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |  32 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |  20 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  29 +++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  18 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  55 --
 drivers/gpu/drm/exynos/exynos_mixer.c   |  15 +-
 include/linux/pending_components.h  |  30 
 20 files changed, 466 insertions(+), 300 deletions(-)
 create mode 100644 drivers/base/pending_components.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm.lds.S
 create mode 100644 include/linux/pending_components.h

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


Re: [PATCH v3 3/5] mfd: tps65090: Stop caching most registers

2014-04-17 Thread Lee Jones
> Nearly all of the registers in tps65090 combine control bits and
> status bits.  Turn off caching of all registers except the select few
> that can be cached.
> 
> In order to avoid adding more duplicate #defines, we also move some
> register offset definitions to the mfd driver (and resolve
> inconsistent names).
> 
> Signed-off-by: Doug Anderson 
> ---
> Changes in v3: None
> Changes in v2:
> - Leave cache on for the registers that can be cached.
> - Move register offsets to mfd header file.
> 
>  drivers/mfd/tps65090.c   | 27 ++-
>  drivers/power/tps65090-charger.c | 11 ---
>  include/linux/mfd/tps65090.h | 14 ++
>  3 files changed, 28 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
> index c3cddb4..1c3e6e2 100644
> --- a/drivers/mfd/tps65090.c
> +++ b/drivers/mfd/tps65090.c
> @@ -32,14 +32,6 @@
>  #define NUM_INT_REG 2
>  #define TOTAL_NUM_REG 0x18
>  
> -/* interrupt status registers */
> -#define TPS65090_INT_STS 0x0
> -#define TPS65090_INT_STS20x1
> -
> -/* interrupt mask registers */
> -#define TPS65090_INT_MSK 0x2
> -#define TPS65090_INT_MSK20x3
> -
>  #define TPS65090_INT1_MASK_VAC_STATUS_CHANGE 1
>  #define TPS65090_INT1_MASK_VSYS_STATUS_CHANGE2
>  #define TPS65090_INT1_MASK_BAT_STATUS_CHANGE 3
> @@ -144,17 +136,26 @@ static struct regmap_irq_chip tps65090_irq_chip = {
>   .irqs = tps65090_irqs,
>   .num_irqs = ARRAY_SIZE(tps65090_irqs),
>   .num_regs = NUM_INT_REG,
> - .status_base = TPS65090_INT_STS,
> - .mask_base = TPS65090_INT_MSK,
> + .status_base = TPS65090_REG_INTR_STS,
> + .mask_base = TPS65090_REG_INTR_MASK,
>   .mask_invert = true,
>  };
>  
>  static bool is_volatile_reg(struct device *dev, unsigned int reg)
>  {
> - if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
> - return true;
> - else
> + /* Nearly all registers have status bits mixed in, except a few */
> + switch (reg) {
> + case TPS65090_REG_INTR_MASK:
> + case TPS65090_REG_INTR_MASK2:
> + case TPS65090_REG_CG_CTRL0:
> + case TPS65090_REG_CG_CTRL1:
> + case TPS65090_REG_CG_CTRL2:
> + case TPS65090_REG_CG_CTRL3:
> + case TPS65090_REG_CG_CTRL4:
> + case TPS65090_REG_CG_CTRL5:
>   return false;
> + }
> + return true;
>  }

I'll not force the issue, but if you wanted to do this more succinctly
you could also do:

  case TPS65090_REG_INTR_MASK ... TPS65090_REG_INTR_MASK:
  case TPS65090_REG_CG_CTRL0  ... TPS65090_REG_CG_CTRL5:

or

  if (reg >= TPS65090_REG_INTR_MASK && reg <= TPS65090_REG_CG_CTRL5)

Ect.

Otherwise patch looks fine:
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 5/8] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-17 Thread Chanwoo Choi
Hi Tushar,

On 04/15/2014 02:09 PM, Tushar Behera wrote:
> On 15 April 2014 07:29, Chanwoo Choi  wrote:
>> This patch fix the offset of CPU boot address and don't operate smc call
>> of SMC_CMD_CPU1BOOT command for Exynos3250.
>>
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Kyungmin Park 
>> ---
>>  arch/arm/mach-exynos/firmware.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/firmware.c 
>> b/arch/arm/mach-exynos/firmware.c
>> index aa01c42..6205d4f 100644
>> --- a/arch/arm/mach-exynos/firmware.c
>> +++ b/arch/arm/mach-exynos/firmware.c
>> @@ -30,13 +30,16 @@ static int exynos_do_idle(void)
>>
>>  static int exynos_cpu_boot(int cpu)
>>  {
>> +   if (soc_is_exynos3250()) {
>> +   return 0;
>> /*
>>  * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
>>  * But, Exynos4212 has only one secondary CPU so second parameter
>>  * isn't used for informing secure firmware about CPU id.
>>  */
>> -   if (soc_is_exynos4212())
>> +   } else if (soc_is_exynos4212()) {
>> cpu = 0;
>> +   }
>>
> 
> As you already return in case of Exynos3250, you need not change this.
> First commit hunk without the opening brace should be sufficient.

OK, I'll remove brace.

Best Regards,
Chanwoo Choi

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


Re: [PATCH 4/5] exynos4-is: Remove requirement for "simple-bus" compatible

2014-04-17 Thread Sylwester Nawrocki
(restoring the Cc list I cleared accidentally in previous reply)

On 16/04/14 21:29, Rob Herring wrote:
> On Wed, Apr 16, 2014 at 12:19 PM, Sylwester Nawrocki
>  wrote:
>> On 16/04/14 17:34, Rob Herring wrote:
>>> On Tue, Apr 15, 2014 at 12:34 PM, Sylwester Nawrocki
>>>  wrote:
> This patch makes the driver instantiating its child devices itself,
> rather than relying on an OS to instantiate devices as children
> of "simple-bus". This removes an incorrect usage of "simple-bus"
> compatible.
>>>
>>> Good, but why can't you use of_platform_populate with the root being
>>> the "samsung,fimc" node? The code to instantiate the devices belongs
>>> in the core OF code.
>>
>> As I mentioned in other thread, I couldn't see anything like
>> of_platform_unpopulate(), which would allow to destroy any created
>> devices. I can't have of_platform_populate() called as last thing
>> in probe() as some drivers do, so at least deferred probe works.
>> Anyway, it wouldn't be a solution since on a driver removal the
>> created devices must be unregistered.
> 
> I think the deferred probe will get fixed in 3.16, but I'm not
> following how deferred probe is relevant here.

What I meant was that when something fails in the middle of probe() 
callback and of_platform_populate() was already called any devices 
created by it must be destroyed before returning an error from probe().
And some drivers seem to never free their devices created by 
of_platform_populate().

>> I read through thread [1] and I didn't immediately have an idea how
>> to fix the core OF code. So I thought I'd come up with this partial
>> solution.
>>
>> I was wondering if creating functions like of_platform_device_delete(),
>> of_amba_device_delete() and a function that would walk device tree and
>> call them would be a way to go ? I could spend some time on that, any
>> suggestions would be appreciated.
> 
> I need to look at the other removal case, but perhaps the way you did
> using children of the struct device parent is the right way. I'm fine
> with that, but I just want to see this in the core code.

All right, I'll have a closer look then if it can be done that way.
 
> Rob
> 
>>
>> --
>> Regards,
>> Sylwester
>>
>> [1] http://www.spinics.net/lists/linux-omap/msg94484.html

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


Re: [PATCH resend] mfd/rtc: s5m: Do not allocate RTC I2C dummy and regmap for unsupported chipsets

2014-04-17 Thread Lee Jones
> The rtc-s5m driver does not support all of S2M and S5M chipsets
> supported by main MFD sec-core driver. For such chipsets unsupported by
> rtc-s5m, the MFD sec-core driver initialized regmap with default config.
> This config in such cases wouldn't work at all.
> 
> The main MFD sec-core driver shouldn't initialize regmap for child
> drivers which is not used by them and even not valid.
> 
> Move the allocation of RTC I2C dummy device and initialization of RTC
> regmap from main MFD sec-core driver to the rtc-s5m driver. The rtc-s5m
> driver will use proper regmap config for supported devices.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/mfd/sec-core.c   | 53 +---
>  drivers/rtc/rtc-s5m.c| 75 
> +---
>  include/linux/mfd/samsung/core.h |  3 --
>  3 files changed, 71 insertions(+), 60 deletions(-)

MFD changes look good to me. If Alessandro provides his Ack for the
RTC adaptions I can setup an MFD-RTC branch for him to pull from in
order to save conflicts at merge time.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 5/8] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-17 Thread Chanwoo Choi
Hi Tomasz,

On 04/16/2014 11:28 PM, Tomasz Figa wrote:
> Hi Chanwoo,
> 
> On 15.04.2014 03:59, Chanwoo Choi wrote:
>> This patch fix the offset of CPU boot address and don't operate smc call
>> of SMC_CMD_CPU1BOOT command for Exynos3250.
>>
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Kyungmin Park 
>> ---
>>   arch/arm/mach-exynos/firmware.c | 7 +--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/firmware.c 
>> b/arch/arm/mach-exynos/firmware.c
>> index aa01c42..6205d4f 100644
>> --- a/arch/arm/mach-exynos/firmware.c
>> +++ b/arch/arm/mach-exynos/firmware.c
>> @@ -30,13 +30,16 @@ static int exynos_do_idle(void)
>>
>>   static int exynos_cpu_boot(int cpu)
>>   {
>> +if (soc_is_exynos3250()) {
>> +return 0;
> 
> This is strange. How the firmware knows when to boot the CPU then, if 
> CPU1BOOT command is not called?

As I knew, Exynos3250 doesn't need smc for secondary boot
because WFE in secure mode for Exynos3250 is removed.
So, Exynos3250 doesn't need to send IPI_WAKEUP after call_firmware_op(cpu_boot, 
...).

Best Regards,
Chanwoo Choi

--
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: [PATCHv3 1/5] drm: exynos: hdmi: remove usage of struct s5p_hdmi_platform_data

2014-04-17 Thread Tomasz Stanislawski
Hi Joonyoung,

On 04/17/2014 03:54 AM, Joonyoung Shim wrote:
> Hi Tomasz,
> 
> On 04/17/2014 12:12 AM, Tomasz Stanislawski wrote:
>> This patch continues shift of DRM EXYNOS to DT-only configuration.
>> The usage of the old structure for HDMI's platform data is
>> removed.
>>
>> Signed-off-by: Tomasz Stanislawski 

[snip]

>>   +ret = drm_hdmi_dt_parse(hdata, dev->of_node);
>> +if (ret)
>> +return -EINVAL;
> 
> It's better to return ret value.
> 

I was considering return ret value. However, I preferred to
be consistent with other 'returns' which returns error literals.

Anyway, I will change it to 'return ret'.

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