Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-10-07 Thread Tomi Valkeinen
On 06/10/14 17:40, Laurent Pinchart wrote:

 But seriously speaking, I was thinking about this. I'd really like to
 have a generic video-mux node, that would still somehow allow us to have
 device specific configurations for the video sources and sinks (which
 the endpoints provide us), without endpoints.

 The reason endpoints don't feel right in this case is that it makes
 sense that the mux has a single input and two outputs, but with
 endpoints we need two endpoints from the bridge (which is still ok), but
 we also need two endpoitns in the mux's input side, which doesn't feel
 right.

 I came up with the following. It's quite ugly, though. I hope someone
 has ideas how it could be done in a neater way:

 bridge1234 {
  bridge1234-cfg1: config1 {
  high-voltage;
  };

  bridge1234-cfg2: config2 {
  low-voltage;
  };

  output = mux;
 };

 mux: video-gpio-mux {
  gpio = 123;

  outputs = panel1 panel2;
  input-configs = bridge1234-cfg1 bridge1234-cfg2;
 };

 panel1: panel-foo {

 };

 panel2: panel-foo {

 };

 So the bridge node has configuration sets. These might be compared to
 pinmux nodes. And the mux has a list of input-configs. When panel1 is to
 be enabled, bridge1234-cfg1 config becomes active, and the bridge is
 given this configuration.

 I have to say the endpoint system feels cleaner than the above, but
 perhaps it's possible to improve the method above somehow.
 
 Isn't it possible for the bridge to compute its configuration at runtime by 
 querying properties of the downstream video entities ? That would solve the 
 problem neatly.

You mean the bridge driver would somehow take a peek into panel1 and
panel2 nodes, looking for bridge specific properties? Sounds somewhat
fragile to me... How would the bridge driver know a property is for the
bridge?

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-10-07 Thread Laurent Pinchart
Hi Tomi,

On Tuesday 07 October 2014 10:06:10 Tomi Valkeinen wrote:
 On 06/10/14 17:40, Laurent Pinchart wrote:
  But seriously speaking, I was thinking about this. I'd really like to
  have a generic video-mux node, that would still somehow allow us to have
  device specific configurations for the video sources and sinks (which
  the endpoints provide us), without endpoints.
  
  The reason endpoints don't feel right in this case is that it makes
  sense that the mux has a single input and two outputs, but with
  endpoints we need two endpoints from the bridge (which is still ok), but
  we also need two endpoitns in the mux's input side, which doesn't feel
  right.
  
  I came up with the following. It's quite ugly, though. I hope someone
  has ideas how it could be done in a neater way:
  
  bridge1234 {
  
 bridge1234-cfg1: config1 {
 
 high-voltage;
 
 };
 
 bridge1234-cfg2: config2 {
 
 low-voltage;
 
 };
 
 output = mux;
  
  };
  
  mux: video-gpio-mux {
  
 gpio = 123;
 
 outputs = panel1 panel2;
 input-configs = bridge1234-cfg1 bridge1234-cfg2;
  
  };
  
  panel1: panel-foo {
  
  };
  
  panel2: panel-foo {
  
  };
  
  So the bridge node has configuration sets. These might be compared to
  pinmux nodes. And the mux has a list of input-configs. When panel1 is to
  be enabled, bridge1234-cfg1 config becomes active, and the bridge is
  given this configuration.
  
  I have to say the endpoint system feels cleaner than the above, but
  perhaps it's possible to improve the method above somehow.
  
  Isn't it possible for the bridge to compute its configuration at runtime
  by querying properties of the downstream video entities ? That would solve
  the problem neatly.
 
 You mean the bridge driver would somehow take a peek into panel1 and
 panel2 nodes, looking for bridge specific properties? Sounds somewhat
 fragile to me... How would the bridge driver know a property is for the
 bridge?

No, I mean the bridge driver should call the API provided by the panel objects 
to get information about the panels, and compute its configuration parameters 
from those. I'm not sure if that's possible though, it depends on whether the 
bridge parameters can be computed from information provided by the panel.

-- 
Regards,

Laurent Pinchart

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


[PATCH v3 0/2] Handle reboot for Exynos SoC via restart_handler

2014-10-07 Thread Pankaj Dubey
This patch removes restart hook from machine_desc of Exynos, and moves
respective code into reboot_notifiers.
Exynos5440 handles reboot via clock register so let's register a
restart_handler in Exynos5440 clock driver.
For rest Exynos SoC, reboot is handled via PMU SWRESET register so
let's register a restart_handler in PMU driver for handling this.

This patch is inspired and dependent on following patch series[1] from
Geunter Roeck.

Also this patch is dependent on PMU platform driver patch [2] by me, and
has been prepared on top of it.

[1]: kernel: Add support for kernel restart handler call chain
https://lkml.org/lkml/2014/8/19/652

[2]: ARM: Exynos: Convert PMU implementation into a platform driver
https://lkml.org/lkml/2014/10/6/89

I have tested reboot functionality on Exynos3250 based board, on
kgene/for-next as well as linux-next's next-20140925 tag.

Patch v2 and related discussion can be found here
http://www.spinics.net/lists/linux-samsung-soc/msg37457.html

Changes since v2:
  - Used register_restart_handler instead of register_reboot_notifier.
  - Updated notifier names and commit message accordingly.

Changes since v1:
  - Addressed review comments from Tomasz Figa. Removed usage of 
local variables where ever unnecessary.
  - Make reg_base as global in clk-exynos5440.c file, to avoid 
iomapping it again in reboot_notifier handler.

Pankaj Dubey (2):
  clk: samsung: exynos5440: move restart code into clock driver
  ARM: EXYNOS: PMU: move restart code into pmu driver

 arch/arm/mach-exynos/common.h|1 -
 arch/arm/mach-exynos/exynos.c|   23 ---
 arch/arm/mach-exynos/pmu.c   |   24 
 drivers/clk/samsung/clk-exynos5440.c |   29 -
 4 files changed, 52 insertions(+), 25 deletions(-)

-- 
1.7.9.5

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


[PATCH v3 2/2] ARM: EXYNOS: PMU: move restart code into pmu driver

2014-10-07 Thread Pankaj Dubey
Let's register restart handler from PMU driver for reboot
functionality. So that we can remove restart hooks from
machine specific file, and thus moving ahead when PMU moved
to driver folder, this functionality can be reused for ARM64
based Exynos SoC's.

Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
 arch/arm/mach-exynos/common.h |1 -
 arch/arm/mach-exynos/exynos.c |6 --
 arch/arm/mach-exynos/pmu.c|   24 
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9019d86..e8afbe6 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -12,7 +12,6 @@
 #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
 #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
 
-#include linux/reboot.h
 #include linux/of.h
 
 #define EXYNOS3250_SOC_ID  0xE3472000
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index e9ddf69..0e0101b 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -137,11 +137,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
 };
 
-static void exynos_restart(enum reboot_mode mode, const char *cmd)
-{
-   __raw_writel(0x1, pmu_base_addr + EXYNOS_SWRESET);
-}
-
 static struct platform_device exynos_cpuidle = {
.name  = exynos_cpuidle,
 #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
@@ -361,7 +356,6 @@ DT_MACHINE_START(EXYNOS_DT, SAMSUNG EXYNOS (Flattened 
Device Tree))
.init_machine   = exynos_dt_machine_init,
.init_late  = exynos_init_late,
.dt_compat  = exynos_dt_compat,
-   .restart= exynos_restart,
.reserve= exynos_reserve,
.dt_fixup   = exynos_dt_fixup,
 MACHINE_END
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 1993e08..0b84998 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -11,7 +11,10 @@
 
 #include linux/io.h
 #include linux/of.h
+#include linux/of_address.h
 #include linux/platform_device.h
+#include linux/notifier.h
+#include linux/reboot.h
 
 #include exynos-pmu.h
 #include regs-pmu.h
@@ -439,6 +442,14 @@ static void exynos5250_pmu_init(void)
pmu_raw_writel(value, EXYNOS5_MASK_WDTRESET_REQUEST);
 }
 
+static int pmu_restart_notify(struct notifier_block *this,
+   unsigned long code, void *unused)
+{
+   pmu_raw_writel(0x1, EXYNOS_SWRESET);
+
+   return NOTIFY_DONE;
+}
+
 static const struct exynos_pmu_data exynos4210_pmu_data = {
.pmu_config = exynos4210_pmu_config,
 };
@@ -478,11 +489,20 @@ static const struct of_device_id 
exynos_pmu_of_device_ids[] = {
{ /*sentinel*/ },
 };
 
+/*
+ * Exynos PMU reboot notifier, handles reboot functionality
+ */
+static struct notifier_block pmu_restart_handler = {
+   .notifier_call = pmu_restart_notify,
+   .priority = 128,
+};
+
 static int exynos_pmu_probe(struct platform_device *pdev)
 {
const struct of_device_id *match;
struct device *dev = pdev-dev;
struct resource *res;
+   int ret;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pmu_base_addr = devm_ioremap_resource(dev, res);
@@ -507,6 +527,10 @@ static int exynos_pmu_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, pmu_context);
 
+   ret = register_restart_handler(pmu_restart_handler);
+   if (ret)
+   dev_err(dev, can't register restart handler err=%d\n, ret);
+
dev_dbg(dev, Exynos PMU Driver probe done\n);
return 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 v3 1/2] clk: samsung: exynos5440: move restart code into clock driver

2014-10-07 Thread Pankaj Dubey
Let's register restart handler for Exynos5440 from it's clock driver
for reboot functionality. So that we can cleanup restart hooks from
machine specific file.

CC: Sylwester Nawrocki s.nawro...@samsung.com
CC: Mike Turquette mturque...@linaro.org
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
 arch/arm/mach-exynos/exynos.c|   19 +--
 drivers/clk/samsung/clk-exynos5440.c |   29 -
 2 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6b283eb..e9ddf69 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -139,24 +139,7 @@ static struct map_desc exynos5_iodesc[] __initdata = {
 
 static void exynos_restart(enum reboot_mode mode, const char *cmd)
 {
-   struct device_node *np;
-   u32 val = 0x1;
-   void __iomem *addr = pmu_base_addr + EXYNOS_SWRESET;
-
-   if (of_machine_is_compatible(samsung,exynos5440)) {
-   u32 status;
-   np = of_find_compatible_node(NULL, NULL, 
samsung,exynos5440-clock);
-
-   addr = of_iomap(np, 0) + 0xbc;
-   status = __raw_readl(addr);
-
-   addr = of_iomap(np, 0) + 0xcc;
-   val = __raw_readl(addr);
-
-   val = (val  0x) | (status  0x);
-   }
-
-   __raw_writel(val, addr);
+   __raw_writel(0x1, pmu_base_addr + EXYNOS_SWRESET);
 }
 
 static struct platform_device exynos_cpuidle = {
diff --git a/drivers/clk/samsung/clk-exynos5440.c 
b/drivers/clk/samsung/clk-exynos5440.c
index 00d1d00..f43b925 100644
--- a/drivers/clk/samsung/clk-exynos5440.c
+++ b/drivers/clk/samsung/clk-exynos5440.c
@@ -15,6 +15,8 @@
 #include linux/clk-provider.h
 #include linux/of.h
 #include linux/of_address.h
+#include linux/notifier.h
+#include linux/reboot.h
 
 #include clk.h
 #include clk-pll.h
@@ -23,6 +25,8 @@
 #define CPU_CLK_STATUS 0xfc
 #define MISC_DOUT1 0x558
 
+static void __iomem *reg_base;
+
 /* parent clock name list */
 PNAME(mout_armclk_p)   = { cplla, cpllb };
 PNAME(mout_spi_p)  = { div125, div200 };
@@ -89,10 +93,30 @@ static const struct of_device_id ext_clk_match[] 
__initconst = {
{},
 };
 
+static int exynos5440_clk_restart_notify(struct notifier_block *this,
+   unsigned long code, void *unused)
+{
+   u32 val, status;
+
+   status = readl_relaxed(reg_base + 0xbc);
+   val = readl_relaxed(reg_base + 0xcc);
+   val = (val  0x) | (status  0x);
+   writel_relaxed(val, reg_base + 0xcc);
+
+   return NOTIFY_DONE;
+}
+
+/*
+ * Exynos5440 Clock reboot notifier, handles reboot functionality
+ */
+static struct notifier_block exynos5440_clk_restart_handler = {
+   .notifier_call = exynos5440_clk_restart_notify,
+   .priority = 128,
+};
+
 /* register exynos5440 clocks */
 static void __init exynos5440_clk_init(struct device_node *np)
 {
-   void __iomem *reg_base;
struct samsung_clk_provider *ctx;
 
reg_base = of_iomap(np, 0);
@@ -125,6 +149,9 @@ static void __init exynos5440_clk_init(struct device_node 
*np)
 
samsung_clk_of_add_provider(np, ctx);
 
+   if (register_restart_handler(exynos5440_clk_restart_handler))
+   pr_err(exynos5440 clock can't register restart handler\n);
+
pr_info(Exynos5440: arm_clk = %ldHz\n, _get_rate(arm_clk));
pr_info(exynos5440 clock initialization complete\n);
 }
-- 
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-10-07 Thread Tomi Valkeinen
On 07/10/14 10:23, Laurent Pinchart wrote:

 You mean the bridge driver would somehow take a peek into panel1 and
 panel2 nodes, looking for bridge specific properties? Sounds somewhat
 fragile to me... How would the bridge driver know a property is for the
 bridge?
 
 No, I mean the bridge driver should call the API provided by the panel 
 objects 
 to get information about the panels, and compute its configuration parameters 
 from those. I'm not sure if that's possible though, it depends on whether the 
 bridge parameters can be computed from information provided by the panel.

Right. My example tried to show a case where they can't be queried. The
board or the wiring causes signal degradation, which can be fixed by
increasing the bridge output voltage slightly.

So it has nothing really to do with the panel, but the board.

I fully admit that it is a purely theoretical case, and I don't have any
real use cases in mind right now.

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [PATCH v7] mfd: syscon: Decouple syscon interface from platform devices

2014-10-07 Thread Lee Jones
On Tue, 30 Sep 2014, Pankaj Dubey wrote:

 Currently a syscon entity can be only registered directly through a
 platform device that binds to a dedicated syscon driver. However in
 certain use cases it is desirable to make a device used with another
 driver a syscon interface provider.
 
 For example, certain SoCs (e.g. Exynos) contain system controller
 blocks which perform various functions such as power domain control,
 CPU power management, low power mode control, but in addition contain
 certain IP integration glue, such as various signal masks,
 coprocessor power control, etc. In such case, there is a need to have
 a dedicated driver for such system controller but also share registers
 with other drivers. The latter is where the syscon interface is helpful.
 
 In case of DT based platforms, this patch decouples syscon object from
 syscon platform driver, and allows to create syscon objects first time
 when it is required by calling of syscon_regmap_lookup_by APIs and keep
 a list of such syscon objects along with syscon provider device_nodes
 and regmap handles.
 
 For non-DT based platforms, this patch keeps syscon platform driver
 structure so that syscon can be probed and such non-DT based drivers
 can use syscon_regmap_lookup_by_pdev API and access regmap handles.
 Once all users of syscon_regmap_lookup_by_pdev migrated to DT based,
 we can completely remove platform driver of syscon, and keep only helper
 functions to get regmap handles.
 
 Suggested-by: Arnd Bergmann a...@arndb.de
 Suggested-by: Tomasz Figa tomasz.f...@gmail.com
 Tested-by: Vivek Gautam gautam.vi...@samsung.com
 Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Reviewed-by: Arnd Bergmann a...@arndb.de
 Tested-by: Heiko Stuebner he...@sntech.de
 Reviewed-by: Heiko Stuebner he...@sntech.de

Applied for v3.19.

 ---
 Patch v6 and related discussions can be found here [1].
 
 Change since v5:
  - Addressed review comments from Heiko Stuebner.
  - Updated commit description.
  - Including Arnd's and Heiko's Reviewed-by.
 
 Change since v5:
  - Dropping creation of dummy platform device in of_syscon_register.
  - As we are changing syscon to decouple from platform_device, creation of 
dummy platform_device does not look good option, and as suggested by Arnd,
I made another attempt so that regmap_mmio_init API should work with NULL
dev pointer itself. Since regmap needs to know about Syscon device node
properties so let's parse device node of syscon in syscon itself for any
such properties and using regmap_config parameter pass all such information
to regmap. Other concern of crashes due to NULL dev pointer in regmap 
 already
addressed in separate patches of regmap. Please see [2] and [3].
 
 Changes since v4:
  - Addressed Tomasz Figa's comments for v4.
  - Added error handing in of_syscon_register function.
  - Using devm_regmap_init_mmio instead of regmap_init_mmio.
 
 Changes since v3:
  - Addressed Arnd's comment for v2.
  - Updated of_syscon_register for adding dev pointer in regmap_init_mmio.
  - For early users created dummy platform device.
 
 Changes since v2:
  - Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
  - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
  - Removed unwanted change in syscon.h.
  - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
  - Added Tested-by of Vivek Gautam for testing on Exynos platform.
 
 Changes since v1:
  - Removed of_syscon_unregister function.
  - Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
  - Removed platform device support from syscon.
  - Removed syscon_regmap_lookup_by_pdevname API support.
  - As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
 
 [1]: https://lkml.org/lkml/2014/9/29/99
 [2]: https://lkml.org/lkml/2014/9/18/130
 [3]: https://lkml.org/lkml/2014/9/27/2
  drivers/mfd/syscon.c |   96 
 ++
  1 file changed, 74 insertions(+), 22 deletions(-)
 
 diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
 index ca15878..72373b1 100644
 --- a/drivers/mfd/syscon.c
 +++ b/drivers/mfd/syscon.c
 @@ -15,6 +15,7 @@
  #include linux/err.h
  #include linux/io.h
  #include linux/module.h
 +#include linux/list.h
  #include linux/of.h
  #include linux/of_address.h
  #include linux/of_platform.h
 @@ -22,31 +23,94 @@
  #include linux/platform_device.h
  #include linux/regmap.h
  #include linux/mfd/syscon.h
 +#include linux/slab.h
  
  static struct platform_driver syscon_driver;
  
 +static DEFINE_SPINLOCK(syscon_list_slock);
 +static LIST_HEAD(syscon_list);
 +
  struct syscon {
 + struct device_node *np;
   struct regmap 

Re: [PATCH v2] [media] Remove references to non-existent PLAT_S5P symbol

2014-10-07 Thread Sylwester Nawrocki
On 06/10/14 18:36, Paul Bolle wrote:
 On Mon, 2014-10-06 at 18:10 +0200, Sylwester Nawrocki wrote:
  The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
  (ARM: SAMSUNG: Remove remaining legacy code). However, there
  are still some references to that symbol left, fix that by
  substituting them with ARCH_S5PV210.
  
  Reported-by: Paul Bolle pebo...@tiscali.nl
  Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com

 Thanks for picking this up!
 
 Should
  Fixes: d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code)
 
 be added so this will end up in stable for v3.17?

Thanks for the suggestion. I will add it to the commit description
and Cc stable before including the patch in a pull request to Mauro.
And will resend the other patch.

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


[PATCH v3] usb: Remove references to non-existent PLAT_S5P symbol

2014-10-07 Thread Sylwester Nawrocki
The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
(ARM: SAMSUNG: Remove remaining legacy code). There are still
some references left, fix that by replacing them with ARCH_S5PV210.

Fixes: d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code)
Reported-by: Paul Bolle pebo...@tiscali.nl
Acked-by: Jingoo Han jg1@samsung.com
Cc: sta...@vger.kernel.org[3.17+]
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes since v2:
 - updated the commit description.

 drivers/usb/host/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..6f1d48e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -220,7 +220,7 @@ config USB_EHCI_SH

 config USB_EHCI_EXYNOS
tristate EHCI support for Samsung S5P/EXYNOS SoC Series
-   depends on PLAT_S5P || ARCH_EXYNOS
+   depends on ARCH_S5PV210 || ARCH_EXYNOS
help
Enable support for the Samsung Exynos SOC's on-chip EHCI controller.

@@ -527,7 +527,7 @@ config USB_OHCI_SH

 config USB_OHCI_EXYNOS
tristate OHCI support for Samsung S5P/EXYNOS SoC Series
-   depends on PLAT_S5P || ARCH_EXYNOS
+   depends on ARCH_S5PV210 || ARCH_EXYNOS
help
 Enable support for the Samsung Exynos SOC's on-chip OHCI controller.

--
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 v9 2/2] ARM: exynos5: Add Suspend-to-RAM support for 5420

2014-10-07 Thread Vikas Sajjan
Adds Suspend-to-RAM support for EXYNOS5420

Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
 arch/arm/mach-exynos/suspend.c |  151 +++-
 1 file changed, 149 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 079d999..8cef614 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -39,6 +39,8 @@
 
 #define REG_TABLE_END (-1U)
 
+#define EXYNOS5420_CPU_STATE   0x28
+
 /**
  * struct exynos_wkup_irq - Exynos GIC to PMU IRQ mapping
  * @hwirq: Hardware IRQ signal of the GIC
@@ -77,6 +79,9 @@ struct exynos_pm_data {
 
 struct exynos_pm_data *pm_data;
 
+static int exynos5420_cpu_state;
+static unsigned int exynos_pmu_spare3;
+
 /*
  * GIC wake-up support
  */
@@ -106,6 +111,23 @@ unsigned int exynos_release_ret_regs[] = {
REG_TABLE_END,
 };
 
+unsigned int exynos5420_release_ret_regs[] = {
+   EXYNOS_PAD_RET_DRAM_OPTION,
+   EXYNOS_PAD_RET_MAUDIO_OPTION,
+   EXYNOS_PAD_RET_JTAG_OPTION,
+   EXYNOS5420_PAD_RET_GPIO_OPTION,
+   EXYNOS5420_PAD_RET_UART_OPTION,
+   EXYNOS5420_PAD_RET_MMCA_OPTION,
+   EXYNOS5420_PAD_RET_MMCB_OPTION,
+   EXYNOS5420_PAD_RET_MMCC_OPTION,
+   EXYNOS5420_PAD_RET_HSI_OPTION,
+   EXYNOS_PAD_RET_EBIA_OPTION,
+   EXYNOS_PAD_RET_EBIB_OPTION,
+   EXYNOS5420_PAD_RET_SPI_OPTION,
+   EXYNOS5420_PAD_RET_DRAM_COREBLK_OPTION,
+   REG_TABLE_END,
+};
+
 static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
 {
const struct exynos_wkup_irq *wkup_irq;
@@ -136,11 +158,22 @@ static int exynos_cpu_do_idle(void)
pr_info(Failed to suspend the system\n);
return 1; /* Aborting suspend */
 }
-
-static int exynos_cpu_suspend(unsigned long arg)
+static void exynos_flush_cache_all(void)
 {
flush_cache_all();
outer_flush_all();
+}
+
+static int exynos_cpu_suspend(unsigned long arg)
+{
+   exynos_flush_cache_all();
+   return exynos_cpu_do_idle();
+}
+
+static int exynos5420_cpu_suspend(unsigned long arg)
+{
+   exynos_flush_cache_all();
+   __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
return exynos_cpu_do_idle();
 }
 
@@ -175,6 +208,50 @@ static void exynos_pm_prepare(void)
exynos_pm_enter_sleep_mode();
 }
 
+static void exynos5420_pm_prepare(void)
+{
+   unsigned int tmp;
+
+   /* Set wake-up mask registers */
+   exynos_pm_set_wakeup_mask();
+
+   s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
+
+   exynos_pmu_spare3 = pmu_raw_readl(S5P_PMU_SPARE3);
+   /*
+* The cpu state needs to be saved and restored so that the
+* secondary CPUs will enter low power start. Though the U-Boot
+* is setting the cpu state with low power flag, the kernel
+* needs to restore it back in case, the primary cpu fails to
+* suspend for any reason.
+*/
+   exynos5420_cpu_state = __raw_readl(sysram_base_addr +
+   EXYNOS5420_CPU_STATE);
+
+   exynos_pm_enter_sleep_mode();
+
+   tmp = pmu_raw_readl(EXYNOS5_ARM_L2_OPTION);
+   tmp = ~EXYNOS5_USE_RETENTION;
+   pmu_raw_writel(tmp, EXYNOS5_ARM_L2_OPTION);
+
+   tmp = pmu_raw_readl(EXYNOS5420_SFR_AXI_CGDIS1);
+   tmp |= EXYNOS5420_UFS;
+   pmu_raw_writel(tmp, EXYNOS5420_SFR_AXI_CGDIS1);
+
+   tmp = pmu_raw_readl(EXYNOS5420_ARM_COMMON_OPTION);
+   tmp = ~EXYNOS5420_L2RSTDISABLE_VALUE;
+   pmu_raw_writel(tmp, EXYNOS5420_ARM_COMMON_OPTION);
+
+   tmp = pmu_raw_readl(EXYNOS5420_FSYS2_OPTION);
+   tmp |= EXYNOS5420_EMULATION;
+   pmu_raw_writel(tmp, EXYNOS5420_FSYS2_OPTION);
+
+   tmp = pmu_raw_readl(EXYNOS5420_PSGEN_OPTION);
+   tmp |= EXYNOS5420_EMULATION;
+   pmu_raw_writel(tmp, EXYNOS5420_PSGEN_OPTION);
+}
+
+
 static int exynos_pm_suspend(void)
 {
exynos_pm_central_suspend();
@@ -185,6 +262,24 @@ static int exynos_pm_suspend(void)
return 0;
 }
 
+static int exynos5420_pm_suspend(void)
+{
+   u32 this_cluster;
+
+   exynos_pm_central_suspend();
+
+   /* Setting SEQ_OPTION register */
+
+   this_cluster = MPIDR_AFFINITY_LEVEL(read_cpuid_mpidr(), 1);
+   if (!this_cluster)
+   pmu_raw_writel(EXYNOS5420_ARM_USE_STANDBY_WFI0,
+   S5P_CENTRAL_SEQ_OPTION);
+   else
+   pmu_raw_writel(EXYNOS5420_KFC_USE_STANDBY_WFI0,
+   S5P_CENTRAL_SEQ_OPTION);
+   return 0;
+}
+
 static void exynos_pm_release_retention(void)
 {
unsigned int i;
@@ -223,6 +318,45 @@ early_wakeup:
pmu_raw_writel(0x0, S5P_INFORM1);
 }
 
+static void exynos5420_pm_resume(void)
+{
+   unsigned long tmp;
+
+   /* Restore the sysram cpu state register */
+   __raw_writel(exynos5420_cpu_state,
+   sysram_base_addr + 

[PATCH v9 1/2] ARM: exynos5: Add PMU support for 5420

2014-10-07 Thread Vikas Sajjan
From: Abhilash Kesavan a.kesa...@samsung.com

Adds intial PMU settings for exynos5420. This is required for
future S2R and Switching support.

Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
 arch/arm/mach-exynos/pmu.c  |  287 +++
 arch/arm/mach-exynos/regs-pmu.h |  227 +++
 2 files changed, 514 insertions(+)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index b68cd29a..4110281 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -12,6 +12,8 @@
 #include linux/io.h
 #include linux/of.h
 #include linux/platform_device.h
+#include linux/delay.h
+
 
 #include exynos-pmu.h
 #include regs-pmu.h
@@ -348,6 +350,151 @@ static const struct exynos_pmu_conf 
exynos5250_pmu_config[] = {
{ PMU_TABLE_END,},
 };
 
+static struct exynos_pmu_conf exynos5420_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+   { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5_ISP_ARM_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5420_ARM_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_ARM_L2_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_L2_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 
0x1} },
+   { EXYNOS5_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 
0x0} },
+   { EXYNOS5_CMU_ACLKSTOP_SYSMEM_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_CMU_SCLKSTOP_SYSMEM_SYS_PWR_REG,  { 0x1, 0x0, 
0x1} },
+   { EXYNOS5_CMU_RESET_SYSMEM_SYS_PWR_REG, { 0x1, 0x1, 
0x0} },
+   { EXYNOS5_DRAM_FREQ_DOWN_SYS_PWR_REG,   { 0x1, 0x0, 
0x1} },
+   { EXYNOS5_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 
0x1} },
+   { EXYNOS5_DDRPHY_DLLLOCK_SYS_PWR_REG,   { 0x1, 0x0, 
0x1} },
+   { EXYNOS5_APLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_MPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_VPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_EPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x1, 
0x0} },
+   { EXYNOS5_BPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_CPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { 

[PATCH v9 0/2] Adds PMU and S2R support for exynos5420

2014-10-07 Thread Vikas Sajjan
Rebased on
1] Kukjin Kim's tree, for-next branch
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next
2] Pankaj Dubey's v9 PMU patchset
http://www.spinics.net/lists/arm-kernel/msg367939.html

changes since v8:
- addressed abhilash's comments to remove the restoring of 
  the CPU0 low power state register, since it will taken care in mcpm 
s2r
  patch from abhilash.

changes since v7:
- rebased on pankaj's latest patchset.

changes since v6:
- rebased on 3.17.rc1.

changes since v5:
- Refactored pm.c to use DT based lookup as suggested by Tomasz Figa.

changes since v4:
- Adressed comments from Tomasz figa and rebased on Pankaj Dubey's v5 
PMU patchset

changes since v3:
Addressed the following comments from Pankaj Dubey, Bartlomiej Zolnierkiewicz,
Tomasz Figa and Alim Akhtar:
- Moved EXYNOS5420_USE_STANDBY_WFI_ALL define to regs-pmu.h.
- Merged exynos5420_set_core_flag function into powerdown_conf.
- Removed XXTI_DURATION3 register setting.
- Updated the commit message and ordered the clock registers in clock
  patch.
- Removed the code for SYS_DISP1_BLK_CFG handling.
- Modified SoC checks to A9 specific checks in PM code.
- Updated some comments in the code and added macros for register 
offsets.
- Fixed code which was changing pad retention code for older SoCs.

changes since v2:
- Addressed comments from Tomasz figa
- rebased on Pankaj's V3 patchset https://lkml.org/lkml/2014/5/2/612
- dropped patch ARM: dts: Add node for GPIO keys on SMDK5420,
  will be sent separately.

changes since v1:
- Addressed comments from Tomasz figa.
- restructured/consolidated as per Tomasz figa's PM consolidations for 
exynos

Tested on Kukjin Kim's tree, for-next branch + 
1] http://www.spinics.net/lists/linux-samsung-soc/msg33750.html
2] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg37260.html
3] with the CLK_IGNORE_UNUSED flag for aclk200_disp1 CLK

on Exynos5420 based chromebook (peach-pit board)

Below procedures were followed to test S2R:
Procedure A:
1. make multi_v7_defconfig 
2  enable MCPM for 5420
3. enable S3C RTC
5. echo +20  /sys/class/rtc/rtc0/wakealarm  echo mem  
/sys/power/state
Procedure B:
1. make exynos_defconfig 
4. echo +20  /sys/class/rtc/rtc0/wakealarm  echo mem  
/sys/power/state

Abhilash Kesavan (1):
  ARM: exynos5: Add PMU support for 5420

Vikas Sajjan (1):
  ARM: exynos5: Add Suspend-to-RAM support for 5420

 arch/arm/mach-exynos/pmu.c  |  287 +++
 arch/arm/mach-exynos/regs-pmu.h |  227 +++
 arch/arm/mach-exynos/suspend.c  |  151 +++-
 3 files changed, 663 insertions(+), 2 deletions(-)

-- 
1.7.9.5

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


[PATCH v2 4/4] phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS

2014-10-07 Thread Vivek Gautam
This PHY controller is also present on Exynos7 platform
in arch-exynos family.
So PHY_EXYNOS5_USBDRD should now depend on ARCH_EXYNOS.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 drivers/phy/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2a436e6..1514e40 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -193,7 +193,7 @@ config PHY_EXYNOS5250_USB2
 
 config PHY_EXYNOS5_USBDRD
tristate Exynos5 SoC series USB DRD PHY driver
-   depends on ARCH_EXYNOS5  OF
+   depends on ARCH_EXYNOS  OF
depends on HAS_IOMEM
depends on USB_DWC3_EXYNOS
select GENERIC_PHY
-- 
1.7.10.4

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


[PATCH v2 0/4] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7

2014-10-07 Thread Vivek Gautam
Adding required support for clocks and additional VBUS regulators
to enable USB 3.0 support on Exynos7 SoC.

This series depends for ACRH_EXYNOS7 support on following series:
[PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC
http://www.spinics.net/lists/linux-samsung-soc/msg37047.html

The series is based on usb-next branch.

Changes since v1:
 -- Addressed review comments for unnecessary warning messages after
clk_get() fails for dwc3-exynos and phy-exynos5-usbdrd.
 -- Assigned exynos-sclk as well as phy_drd-utmiclk and
phy_drd-pipeclk to NULL in case of clk_get() failure to avoid
unnecessary check for clock.
 -- Modified dependency for symbol PHY_EXYNOS5_USBDRD to depend on
ARCH_EXYNOS which includes both Exynos5 as well as Exynos7.
 -- Dropped [PATCH 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
from v1 of this series, since its not required now.

Vivek Gautam (4):
  dwc3: exynos: Add support for SCLK present on Exynos7
  phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support
  phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
  phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS

 .../devicetree/bindings/phy/samsung-phy.txt|4 ++
 drivers/phy/Kconfig|2 +-
 drivers/phy/phy-exynos5-usbdrd.c   |   52 +++-
 drivers/usb/dwc3/dwc3-exynos.c |   16 ++
 4 files changed, 71 insertions(+), 3 deletions(-)

-- 
1.7.10.4

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


[PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-07 Thread Vivek Gautam
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 drivers/usb/dwc3/dwc3-exynos.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 3951a65..7dc6a98 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device   *dev;
 
struct clk  *clk;
+   struct clk  *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
 };
@@ -139,10 +140,21 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+   /*
+* Exynos7 has a special gate clock going to this IP,
+* which in earlier SoCs was probably concealed.
+*/
+   exynos-sclk = devm_clk_get(dev, usbdrd30_sclk);
+   if (IS_ERR(exynos-sclk)) {
+   dev_info(dev, no sclk specified\n);
+   exynos-sclk = NULL;
+   }
+
exynos-dev = dev;
exynos-clk = clk;
 
clk_prepare_enable(exynos-clk);
+   clk_prepare_enable(exynos-sclk);
 
exynos-vdd33 = devm_regulator_get(dev, vdd33);
if (IS_ERR(exynos-vdd33)) {
@@ -185,6 +197,7 @@ err4:
 err3:
regulator_disable(exynos-vdd33);
 err2:
+   clk_disable_unprepare(exynos-sclk);
clk_disable_unprepare(clk);
return ret;
 }
@@ -197,6 +210,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
 
+   clk_disable_unprepare(exynos-sclk);
clk_disable_unprepare(exynos-clk);
 
regulator_disable(exynos-vdd33);
@@ -218,6 +232,7 @@ static int dwc3_exynos_suspend(struct device *dev)
 {
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 
+   clk_disable(exynos-sclk);
clk_disable(exynos-clk);
 
regulator_disable(exynos-vdd33);
@@ -243,6 +258,7 @@ static int dwc3_exynos_resume(struct device *dev)
}
 
clk_enable(exynos-clk);
+   clk_enable(exynos-sclk);
 
/* runtime set active to reflect active state. */
pm_runtime_disable(dev);
-- 
1.7.10.4

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


[PATCH v2 3/4] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply

2014-10-07 Thread Vivek Gautam
Some Exynos SoCs have a separate regulator controlling a
Boost 5V supply which goes as input for VBUS regulator.
So adding a control for the same in driver, to enable
vbus supply on the port.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 drivers/phy/phy-exynos5-usbdrd.c |   30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 013ee84..57e8a0a 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -176,6 +176,7 @@ struct exynos5_usbdrd_phy {
u32 extrefclk;
struct clk *ref_clk;
struct regulator *vbus;
+   struct regulator *vbus_boost;
 };
 
 static inline
@@ -455,11 +456,20 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd-ref_clk);
 
/* Enable VBUS supply */
+   if (phy_drd-vbus_boost) {
+   ret = regulator_enable(phy_drd-vbus_boost);
+   if (ret) {
+   dev_err(phy_drd-dev,
+   Failed to enable VBUS boost supply\n);
+   goto fail_vbus;
+   }
+   }
+
if (phy_drd-vbus) {
ret = regulator_enable(phy_drd-vbus);
if (ret) {
dev_err(phy_drd-dev, Failed to enable VBUS supply\n);
-   goto fail_vbus;
+   goto fail_vbus_boost;
}
}
 
@@ -468,6 +478,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
return 0;
 
+fail_vbus_boost:
+   if (phy_drd-vbus_boost)
+   regulator_disable(phy_drd-vbus_boost);
+
 fail_vbus:
clk_disable_unprepare(phy_drd-ref_clk);
clk_disable_unprepare(phy_drd-pipeclk);
@@ -489,6 +503,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Disable VBUS supply */
if (phy_drd-vbus)
regulator_disable(phy_drd-vbus);
+   if (phy_drd-vbus_boost)
+   regulator_disable(phy_drd-vbus_boost);
 
clk_disable_unprepare(phy_drd-ref_clk);
clk_disable_unprepare(phy_drd-pipeclk);
@@ -644,7 +660,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
break;
}
 
-   /* Get Vbus regulator */
+   /* Get Vbus regulators */
phy_drd-vbus = devm_regulator_get(dev, vbus);
if (IS_ERR(phy_drd-vbus)) {
ret = PTR_ERR(phy_drd-vbus);
@@ -655,6 +671,16 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
phy_drd-vbus = NULL;
}
 
+   phy_drd-vbus_boost = devm_regulator_get(dev, vbus-boost);
+   if (IS_ERR(phy_drd-vbus_boost)) {
+   ret = PTR_ERR(phy_drd-vbus_boost);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
+   dev_warn(dev, Failed to get VBUS boost supply regulator\n);
+   phy_drd-vbus_boost = NULL;
+   }
+
dev_vdbg(dev, Creating usbdrd_phy phy\n);
 
for (i = 0; i  EXYNOS5_DRDPHYS_NUM; i++) {
-- 
1.7.10.4

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


[PATCH v2 2/4] phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support

2014-10-07 Thread Vivek Gautam
Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
clock, as well as 60MHz utmi phy clock.
So get the same and control in the phy-exynos5-usbdrd driver.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 .../devicetree/bindings/phy/samsung-phy.txt|4 
 drivers/phy/phy-exynos5-usbdrd.c   |   22 
 2 files changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 15e0f2c..c2bc9dc 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -138,6 +138,10 @@ Required properties:
   PHY operations, associated by phy name. It is used to
   determine bit values for clock settings register.
   For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+   - optional clocks: Exynos7 SoC has now following additional
+  gate clocks available:
+  - phy_pipe: for PIPE3 phy
+  - phy_utmi: for UTMI+ phy
 - samsung,pmu-syscon: phandle for PMU system controller interface, used to
  control pmu registers for power isolation.
 - #phy-cells : from the generic PHY bindings, must be 1;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index f756aca..013ee84 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -148,6 +148,8 @@ struct exynos5_usbdrd_phy_drvdata {
  * @dev: pointer to device instance of this platform device
  * @reg_phy: usb phy controller register memory base
  * @clk: phy clock for register access
+ * @pipeclk: clock for pipe3 phy
+ * @utmiclk: clock for utmi+ phy
  * @drv_data: pointer to SoC level driver data structure
  * @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
  * instances each with its 'phy' and 'phy_cfg'.
@@ -161,6 +163,8 @@ struct exynos5_usbdrd_phy {
struct device *dev;
void __iomem *reg_phy;
struct clk *clk;
+   struct clk *pipeclk;
+   struct clk *utmiclk;
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct phy_usb_instance {
struct phy *phy;
@@ -446,6 +450,8 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
dev_dbg(phy_drd-dev, Request to power_on usbdrd_phy phy\n);
 
+   clk_prepare_enable(phy_drd-utmiclk);
+   clk_prepare_enable(phy_drd-pipeclk);
clk_prepare_enable(phy_drd-ref_clk);
 
/* Enable VBUS supply */
@@ -464,6 +470,8 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
 fail_vbus:
clk_disable_unprepare(phy_drd-ref_clk);
+   clk_disable_unprepare(phy_drd-pipeclk);
+   clk_disable_unprepare(phy_drd-utmiclk);
 
return ret;
 }
@@ -483,6 +491,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
regulator_disable(phy_drd-vbus);
 
clk_disable_unprepare(phy_drd-ref_clk);
+   clk_disable_unprepare(phy_drd-pipeclk);
+   clk_disable_unprepare(phy_drd-utmiclk);
 
return 0;
 }
@@ -582,6 +592,18 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
return PTR_ERR(phy_drd-clk);
}
 
+   phy_drd-pipeclk = devm_clk_get(dev, phy_pipe);
+   if (IS_ERR(phy_drd-pipeclk)) {
+   dev_info(dev, PIPE3 phy operational clock not specified\n);
+   phy_drd-pipeclk = NULL;
+   }
+
+   phy_drd-utmiclk = devm_clk_get(dev, phy_utmi);
+   if (IS_ERR(phy_drd-utmiclk)) {
+   dev_info(dev, UTMI phy operational clock not specified\n);
+   phy_drd-utmiclk = NULL;
+   }
+
phy_drd-ref_clk = devm_clk_get(dev, ref);
if (IS_ERR(phy_drd-ref_clk)) {
dev_err(dev, Failed to get reference clock of usbdrd phy\n);
-- 
1.7.10.4

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


Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-10-07 Thread Tomi Valkeinen
On 20/09/14 14:22, Ajay kumar wrote:

 Well, I am okay with using video ports to describe the relationship
 between the encoder, bridge and the panel.
 But, its just that I need to make use of 2 functions when phandle
 does it using just one function ;)
 -panel_node = of_parse_phandle(dev-of_node, panel, 0)
 +   endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
 +   if (!endpoint)
 +   return -EPROBE_DEFER;
 +
 +   panel_node = of_graph_get_remote_port_parent(endpoint);
 +   if (!panel_node)
 +   return -EPROBE_DEFER;
 
 
 If nobody else has objections over using of_graph functions instead
 of phandles, I can respin this patchset by making use of video ports.

The discussion did digress somewhat.

As a clarification, I'm in no way nack'ing this series because it
doesn't use the graphs for video connections. I don't see the simple
phandle bindings used here as broken as such.

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-10-07 Thread Ajay kumar
On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 20/09/14 14:22, Ajay kumar wrote:

 Well, I am okay with using video ports to describe the relationship
 between the encoder, bridge and the panel.
 But, its just that I need to make use of 2 functions when phandle
 does it using just one function ;)
 -panel_node = of_parse_phandle(dev-of_node, panel, 0)
 +   endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
 +   if (!endpoint)
 +   return -EPROBE_DEFER;
 +
 +   panel_node = of_graph_get_remote_port_parent(endpoint);
 +   if (!panel_node)
 +   return -EPROBE_DEFER;


 If nobody else has objections over using of_graph functions instead
 of phandles, I can respin this patchset by making use of video ports.

 The discussion did digress somewhat.

 As a clarification, I'm in no way nack'ing this series because it
 doesn't use the graphs for video connections. I don't see the simple
 phandle bindings used here as broken as such.
Well, I am okay with any approach you guys decide on. I desperately want
this to get this in since it has been floating around for quite sometime.
The more we drag this, the more rework for me since the number of platforms
using bridge support is increasing daily!

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


[PATCH 2/4] drm/exynos/dsi: simplify device pointer evaluation

2014-10-07 Thread Andrzej Hajda
The patch replaces multiple evaluation of device address
with local variable.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 40 -
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 84e3808..39ec450 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1695,9 +1695,9 @@ static int exynos_dsi_probe(struct platform_device *pdev)
INIT_LIST_HEAD(dsi-transfer_list);
 
dsi-dsi_host.ops = exynos_dsi_ops;
-   dsi-dsi_host.dev = pdev-dev;
+   dsi-dsi_host.dev = dev;
 
-   dsi-dev = pdev-dev;
+   dsi-dev = dev;
dsi-driver_data = exynos_dsi_get_driver_data(pdev);
 
ret = exynos_dsi_parse_dt(dsi);
@@ -1706,70 +1706,70 @@ static int exynos_dsi_probe(struct platform_device 
*pdev)
 
dsi-supplies[0].supply = vddcore;
dsi-supplies[1].supply = vddio;
-   ret = devm_regulator_bulk_get(pdev-dev, ARRAY_SIZE(dsi-supplies),
+   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi-supplies),
  dsi-supplies);
if (ret) {
-   dev_info(pdev-dev, failed to get regulators: %d\n, ret);
+   dev_info(dev, failed to get regulators: %d\n, ret);
return -EPROBE_DEFER;
}
 
-   dsi-pll_clk = devm_clk_get(pdev-dev, pll_clk);
+   dsi-pll_clk = devm_clk_get(dev, pll_clk);
if (IS_ERR(dsi-pll_clk)) {
-   dev_info(pdev-dev, failed to get dsi pll input clock\n);
+   dev_info(dev, failed to get dsi pll input clock\n);
ret = PTR_ERR(dsi-pll_clk);
goto err_del_component;
}
 
-   dsi-bus_clk = devm_clk_get(pdev-dev, bus_clk);
+   dsi-bus_clk = devm_clk_get(dev, bus_clk);
if (IS_ERR(dsi-bus_clk)) {
-   dev_info(pdev-dev, failed to get dsi bus clock\n);
+   dev_info(dev, failed to get dsi bus clock\n);
ret = PTR_ERR(dsi-bus_clk);
goto err_del_component;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   dsi-reg_base = devm_ioremap_resource(pdev-dev, res);
+   dsi-reg_base = devm_ioremap_resource(dev, res);
if (IS_ERR(dsi-reg_base)) {
-   dev_err(pdev-dev, failed to remap io region\n);
+   dev_err(dev, failed to remap io region\n);
ret = PTR_ERR(dsi-reg_base);
goto err_del_component;
}
 
-   dsi-phy = devm_phy_get(pdev-dev, dsim);
+   dsi-phy = devm_phy_get(dev, dsim);
if (IS_ERR(dsi-phy)) {
-   dev_info(pdev-dev, failed to get dsim phy\n);
+   dev_info(dev, failed to get dsim phy\n);
ret = PTR_ERR(dsi-phy);
goto err_del_component;
}
 
dsi-irq = platform_get_irq(pdev, 0);
if (dsi-irq  0) {
-   dev_err(pdev-dev, failed to request dsi irq resource\n);
+   dev_err(dev, failed to request dsi irq resource\n);
ret = dsi-irq;
goto err_del_component;
}
 
irq_set_status_flags(dsi-irq, IRQ_NOAUTOEN);
-   ret = devm_request_threaded_irq(pdev-dev, dsi-irq, NULL,
+   ret = devm_request_threaded_irq(dev, dsi-irq, NULL,
exynos_dsi_irq, IRQF_ONESHOT,
-   dev_name(pdev-dev), dsi);
+   dev_name(dev), dsi);
if (ret) {
-   dev_err(pdev-dev, failed to request dsi irq\n);
+   dev_err(dev, failed to request dsi irq\n);
goto err_del_component;
}
 
-   exynos_dsi_display.ctx = dsi;
+   dsi-display.ctx = dsi;
 
-   platform_set_drvdata(pdev, exynos_dsi_display);
+   platform_set_drvdata(pdev, dsi-display);
 
-   ret = component_add(pdev-dev, exynos_dsi_component_ops);
+   ret = component_add(dev, exynos_dsi_component_ops);
if (ret)
goto err_del_component;
 
return ret;
 
 err_del_component:
-   exynos_drm_component_del(pdev-dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
+   exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
return ret;
 }
 
-- 
1.9.1

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


[PATCH 0/4] drm/exynos/dsi: remove global display variable

2014-10-07 Thread Andrzej Hajda
Hi Inki,

Many Exynos DRM drivers uses global variables to represent associated devices
in Exynos DRM internal framework. It is quite confusing, it adds data 
duplication
and finally it does not allow to handle more than one device in system.
It seems better to embed such structures in private context of the device.

The patchset is based on exynos_drm_next plus my patch [1]:
'drm/exynos: remove explicit encoder/connector de-initialization'.

If the patchset is OK for you I can prepare similar patches for other Exynos 
DRM components.

[1]: https://lkml.org/lkml/2014/9/22/148

Regards
Andrzej


Andrzej Hajda (4):
  drm/exynos/dsi: remove global variable exynos_dsi_display
  drm/exynos/dsi: simplify device pointer evaluation
  drm/exynos/dsi: remove redundant encoder field
  drm/exynos/dsi: stop using display-ctx pointer

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 96 -
 1 file changed, 47 insertions(+), 49 deletions(-)

-- 
1.9.1

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


[PATCH 1/4] drm/exynos/dsi: remove global variable exynos_dsi_display

2014-10-07 Thread Andrzej Hajda
exynos_dsi_display is used by internal Exynos DRM framework for
representing pair encoder-connecter. As it should be mapped 1:1 to dsi
private context it seems more reasonable to embed it directly
in that context. As a result further code simplification will be possible.
Moreover it will be possible to handle multiple DSI devices in the system.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 38 -
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index acf7e9e..84e3808 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -268,6 +268,7 @@ struct exynos_dsi_driver_data {
 };
 
 struct exynos_dsi {
+   struct exynos_drm_display display;
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
struct drm_encoder *encoder;
@@ -1531,10 +1532,6 @@ static struct exynos_drm_display_ops 
exynos_dsi_display_ops = {
.dpms = exynos_dsi_dpms
 };
 
-static struct exynos_drm_display exynos_dsi_display = {
-   .type = EXYNOS_DISPLAY_TYPE_LCD,
-   .ops = exynos_dsi_display_ops,
-};
 MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
 
 /* of_* functions will be removed after merge of of_graph patches */
@@ -1640,28 +1637,28 @@ end:
 static int exynos_dsi_bind(struct device *dev, struct device *master,
void *data)
 {
+   struct exynos_drm_display *display = dev_get_drvdata(dev);
+   struct exynos_dsi *dsi = display-ctx;
struct drm_device *drm_dev = data;
-   struct exynos_dsi *dsi;
int ret;
 
-   ret = exynos_drm_create_enc_conn(drm_dev, exynos_dsi_display);
+   ret = exynos_drm_create_enc_conn(drm_dev, display);
if (ret) {
DRM_ERROR(Encoder create [%d] failed with %d\n,
-   exynos_dsi_display.type, ret);
+ display-type, ret);
return ret;
}
 
-   dsi = exynos_dsi_display.ctx;
-
return mipi_dsi_host_register(dsi-dsi_host);
 }
 
 static void exynos_dsi_unbind(struct device *dev, struct device *master,
void *data)
 {
-   struct exynos_dsi *dsi = exynos_dsi_display.ctx;
+   struct exynos_drm_display *display = dev_get_drvdata(dev);
+   struct exynos_dsi *dsi = display-ctx;
 
-   exynos_dsi_dpms(exynos_dsi_display, DRM_MODE_DPMS_OFF);
+   exynos_dsi_dpms(display, DRM_MODE_DPMS_OFF);
 
mipi_dsi_host_unregister(dsi-dsi_host);
 }
@@ -1673,22 +1670,23 @@ static const struct component_ops 
exynos_dsi_component_ops = {
 
 static int exynos_dsi_probe(struct platform_device *pdev)
 {
+   struct device *dev = pdev-dev;
struct resource *res;
struct exynos_dsi *dsi;
int ret;
 
-   ret = exynos_drm_component_add(pdev-dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
-   exynos_dsi_display.type);
+   dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
+   if (!dsi)
+   return -ENOMEM;
+
+   dsi-display.type = EXYNOS_DISPLAY_TYPE_LCD;
+   dsi-display.ops = exynos_dsi_display_ops;
+
+   ret = exynos_drm_component_add(dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
+  dsi-display.type);
if (ret)
return ret;
 
-   dsi = devm_kzalloc(pdev-dev, sizeof(*dsi), GFP_KERNEL);
-   if (!dsi) {
-   dev_err(pdev-dev, failed to allocate dsi object.\n);
-   ret = -ENOMEM;
-   goto err_del_component;
-   }
-
/* To be checked as invalid one */
dsi-te_gpio = -ENOENT;
 
-- 
1.9.1

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


Re: [PATCH] drm/exynos: init vblank with real number of crtcs

2014-10-07 Thread Andrzej Hajda
Hi Inki,

Gently ping.

Andrzej


On 09/19/2014 02:57 PM, Andrzej Hajda wrote:
 Initialization of vblank with MAX_CRTC caused attempts
 to disabling vblanks for non-existing crtcs in case
 drm used fewer crtcs. The patch fixes it.
 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index 9b00e4e..dc4affd 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, 
 unsigned long flags)
   /* init kms poll for handling hpd */
   drm_kms_helper_poll_init(dev);
  
 - ret = drm_vblank_init(dev, MAX_CRTC);
 - if (ret)
 - goto err_mode_config_cleanup;
 -
   /* setup possible_clones. */
   exynos_drm_encoder_setup(dev);
  
 @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, 
 unsigned long flags)
   /* Try to bind all sub drivers. */
   ret = component_bind_all(dev-dev, dev);
   if (ret)
 - goto err_cleanup_vblank;
 + goto err_mode_config_cleanup;
 +
 + ret = drm_vblank_init(dev, dev-mode_config.num_crtc);
 + if (ret)
 + goto err_unbind_all;
  
   /* Probe non kms sub drivers and virtual display driver. */
   ret = exynos_drm_device_subdrv_probe(dev);
   if (ret)
 - goto err_unbind_all;
 + goto err_cleanup_vblank;
  
   /* force connectors detection */
   drm_helper_hpd_irq_event(dev);
  
   return 0;
  
 -err_unbind_all:
 - component_unbind_all(dev-dev, dev);
  err_cleanup_vblank:
   drm_vblank_cleanup(dev);
 +err_unbind_all:
 + component_unbind_all(dev-dev, dev);
  err_mode_config_cleanup:
   drm_mode_config_cleanup(dev);
   drm_release_iommu_mapping(dev);
 @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev)
   exynos_drm_fbdev_fini(dev);
   drm_kms_helper_poll_fini(dev);
  
 - component_unbind_all(dev-dev, dev);
   drm_vblank_cleanup(dev);
 + component_unbind_all(dev-dev, dev);
   drm_mode_config_cleanup(dev);
   drm_release_iommu_mapping(dev);
  
 

--
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 v9 1/2] ARM: EXYNOS: Add platform driver support for Exynos PMU

2014-10-07 Thread Javier Martinez Canillas
Hello Pankaj,

On Mon, Oct 6, 2014 at 11:26 AM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 This patch modifies Exynos Power Management Unit (PMU) initialization
 implementation in following way:

 - Added platform driver support for Exynos PMU IP.
 - Added platform struct exynos_pmu_data to hold platform specific data.
 - For each SoC's PMU support now we can add platform data and statically
   bind PMU configuration and SoC specific initialization function.
 - Separate each SoC's PMU initialization function and make it as part of
   platform data.
 - It also removes uses of soc_is_exynosXYZ().

 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig |1 +
  arch/arm/mach-exynos/pmu.c   |  171 
 +++---
  2 files changed, 130 insertions(+), 42 deletions(-)


Suspend-to-RAM is working on my Exynos5420 Peach Pit Chromebook, so:

Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Best regards,
Javier
--
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 v9 2/2] ARM: EXYNOS: Move PMU specific definitions from common.h

2014-10-07 Thread Javier Martinez Canillas
Hello Pankaj,

On Mon, Oct 6, 2014 at 11:26 AM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 This patch moves PMU specific definitions into a new file
 as exynos-pmu.h.
 This will help in reducing dependency of common.h in pmu.c.

 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 ---
  arch/arm/mach-exynos/common.h |   17 -
  arch/arm/mach-exynos/exynos-pmu.h |   24 
  arch/arm/mach-exynos/pm.c |1 +
  arch/arm/mach-exynos/pmu.c|   20 +++-
  arch/arm/mach-exynos/suspend.c|1 +
  5 files changed, 45 insertions(+), 18 deletions(-)
  create mode 100644 arch/arm/mach-exynos/exynos-pmu.h


Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Best regards,
Javier
--
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 v9 1/2] ARM: exynos5: Add PMU support for 5420

2014-10-07 Thread Javier Martinez Canillas
Hellos Vikas,

On Tue, Oct 7, 2014 at 11:22 AM, Vikas Sajjan vikas.saj...@samsung.com wrote:
 From: Abhilash Kesavan a.kesa...@samsung.com

 Adds intial PMU settings for exynos5420. This is required for
 future S2R and Switching support.

 Signed-off-by: Thomas Abraham thomas...@samsung.com
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
 ---
  arch/arm/mach-exynos/pmu.c  |  287 
 +++
  arch/arm/mach-exynos/regs-pmu.h |  227 +++
  2 files changed, 514 insertions(+)

S2R is working on my Exynos5420 Peach Pit Chromebook with your series:

Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Best regards,
Javier
--
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 v9 2/2] ARM: exynos5: Add Suspend-to-RAM support for 5420

2014-10-07 Thread Javier Martinez Canillas
Hello Vikas,

On Tue, Oct 7, 2014 at 11:22 AM, Vikas Sajjan vikas.saj...@samsung.com wrote:
 Adds Suspend-to-RAM support for EXYNOS5420

 Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
  arch/arm/mach-exynos/suspend.c |  151 
 +++-
  1 file changed, 149 insertions(+), 2 deletions(-)


Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

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


[PATCH v3] ARM: EXYNOS: add Exynos3250 PMU support

2014-10-07 Thread Bartlomiej Zolnierkiewicz
This is needed for suspend/resume and cpuidle AFTR mode support.

Cc: Pankaj Dubey pankaj.du...@samsung.com
Cc: Vikas Sajjan vikas.saj...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
v3:
- rebased on top of for-next branch of linux-samsung.git and
  [PATCH v7] mfd: syscon: Decouple syscon interface from platform devices
  (https://lkml.org/lkml/2014/9/30/156)
  [PATCH v9 0/2] ARM: Exynos: Convert PMU implementation into a platform driver
  (https://lkml.org/lkml/2014/10/6/89)
  [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
  (http://www.spinics.net/lists/arm-kernel/msg368207.html)

v2:
- rebased on top of next-20140708 and
  http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32410.html
  http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg33660.html
  http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg33675.html

  this patch also applies fine after/before Exynos5800 PMU support:
  http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg33835.html

 arch/arm/mach-exynos/pmu.c  | 173 
 arch/arm/mach-exynos/regs-pmu.h | 129 ++
 2 files changed, 302 insertions(+)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 98824bc..3bd1038 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -31,6 +31,7 @@ struct exynos_pmu_data {
 
void (*pmu_init)(void);
void (*powerdown_conf)(enum sys_powerdown);
+   void (*powerdown_conf_extra)(enum sys_powerdown);
 };
 
 struct exynos_pmu_context {
@@ -51,6 +52,98 @@ static inline u32 pmu_raw_readl(u32 offset)
return readl_relaxed(pmu_base_addr + offset);
 }
 
+static struct exynos_pmu_conf exynos3250_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, W-AFTR, SLEEP } */
+   { EXYNOS3_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS3_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS3_ARM_CORE2_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS3_ARM_CORE3_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS3_ISP_ARM_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS3_ARM_COMMON_SYS_PWR_REG,   { 0x0, 0x0, 0x2} },
+   { EXYNOS3_ARM_L2_SYS_PWR_REG,   { 0x0, 0x0, 0x3} },
+   { EXYNOS3_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+   { EXYNOS3_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+   { EXYNOS3_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+   { EXYNOS3_DRAM_FREQ_DOWN_SYS_PWR_REG,   { 0x1, 0x1, 0x1} },
+   { EXYNOS3_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 0x1} },
+   { EXYNOS3_LPDDR_PHY_DLL_LOCK_SYS_PWR_REG,   { 0x1, 0x1, 0x1} },
+   { EXYNOS3_CMU_ACLKSTOP_COREBLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+   { EXYNOS3_CMU_SCLKSTOP_COREBLK_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+   { EXYNOS3_CMU_RESET_COREBLK_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+   { EXYNOS3_APLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_MPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_BPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_VPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x1, 0x0} },
+   { EXYNOS3_EPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_UPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x1, 0x1} },
+   { EXYNOS3_EPLLUSER_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_MPLLUSER_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_BPLLUSER_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_CMU_CLKSTOP_CAM_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_CMU_CLKSTOP_MFC_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_CMU_CLKSTOP_G3D_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_CMU_CLKSTOP_LCD0_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+   { EXYNOS3_CMU_CLKSTOP_ISP_SYS_PWR_REG,  

Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-07 Thread Felipe Balbi
On Tue, Oct 07, 2014 at 03:49:33PM +0530, Vivek Gautam wrote:
 Exynos7 also has a separate special gate clock going to the IP
 apart from the usual AHB clock. So add support for the same.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com

I'll take this one once -rc1 is tagged. The others have no direct
dependency on this so I'll leave them to Kishon.

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH] drm/exynos: remove explicit encoder/connector de-initialization

2014-10-07 Thread Andrzej Hajda
Hi Inki,

Another gently ping :)

Andrzej

On 09/22/2014 11:30 AM, Andrzej Hajda wrote:
 All KMS objects are destroyed by drm_mode_config_cleanup in proper order
 so component drivers should not care about it.

 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
 Hi Inki,

 This is another spin-off of exynos_drm tests regarding your
 component support update.
 The patch is based as usual on the latest exynos-drm-next branch.

 Regards
 Andrzej
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c  | 5 -
  drivers/gpu/drm/exynos/exynos_drm_dpi.c  | 4 
  drivers/gpu/drm/exynos/exynos_drm_dsi.c  | 4 
  drivers/gpu/drm/exynos/exynos_drm_vidi.c | 3 ---
  drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
  5 files changed, 22 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index cd50ece..6adb1e5 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1355,13 +1355,8 @@ static void exynos_dp_unbind(struct device *dev, 
 struct device *master,
   void *data)
  {
   struct exynos_drm_display *display = dev_get_drvdata(dev);
 - struct exynos_dp_device *dp = display-ctx;
 - struct drm_encoder *encoder = dp-encoder;
  
   exynos_dp_dpms(display, DRM_MODE_DPMS_OFF);
 -
 - exynos_dp_connector_destroy(dp-connector);
 - encoder-funcs-destroy(encoder);
  }
  
  static const struct component_ops exynos_dp_ops = {
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
 index 96c87db..3dc678e 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
 @@ -338,14 +338,10 @@ err_del_component:
  
  int exynos_dpi_remove(struct device *dev)
  {
 - struct drm_encoder *encoder = exynos_dpi_display.encoder;
   struct exynos_dpi *ctx = exynos_dpi_display.ctx;
  
   exynos_dpi_dpms(exynos_dpi_display, DRM_MODE_DPMS_OFF);
  
 - exynos_dpi_connector_destroy(ctx-connector);
 - encoder-funcs-destroy(encoder);
 -
   if (ctx-panel)
   drm_panel_detach(ctx-panel);
  
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
 index 24741d8..acf7e9e 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
 @@ -1660,13 +1660,9 @@ static void exynos_dsi_unbind(struct device *dev, 
 struct device *master,
   void *data)
  {
   struct exynos_dsi *dsi = exynos_dsi_display.ctx;
 - struct drm_encoder *encoder = dsi-encoder;
  
   exynos_dsi_dpms(exynos_dsi_display, DRM_MODE_DPMS_OFF);
  
 - exynos_dsi_connector_destroy(dsi-connector);
 - encoder-funcs-destroy(encoder);
 -
   mipi_dsi_host_unregister(dsi-dsi_host);
  }
  
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 index d565207..9395e85 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 @@ -639,9 +639,6 @@ static int vidi_remove(struct platform_device *pdev)
   return -EINVAL;
   }
  
 - encoder-funcs-destroy(encoder);
 - drm_connector_cleanup(ctx-connector);
 -
   return 0;
  }
  
 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 7910fb3..563a19e 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -2312,12 +2312,6 @@ static int hdmi_bind(struct device *dev, struct device 
 *master, void *data)
  
  static void hdmi_unbind(struct device *dev, struct device *master, void 
 *data)
  {
 - struct exynos_drm_display *display = get_hdmi_display(dev);
 - struct drm_encoder *encoder = display-encoder;
 - struct hdmi_context *hdata = display-ctx;
 -
 - hdmi_connector_destroy(hdata-connector);
 - encoder-funcs-destroy(encoder);
  }
  
  static const struct component_ops hdmi_component_ops = {

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-10-07 Thread Laurent Pinchart
Hi Ajay,

On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote:
 On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote:
  On 20/09/14 14:22, Ajay kumar wrote:
  Well, I am okay with using video ports to describe the relationship
  between the encoder, bridge and the panel.
  But, its just that I need to make use of 2 functions when phandle
  does it using just one function ;)
  -panel_node = of_parse_phandle(dev-of_node, panel, 0)
  +   endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
  +   if (!endpoint)
  +   return -EPROBE_DEFER;
  +
  +   panel_node = of_graph_get_remote_port_parent(endpoint);
  +   if (!panel_node)
  +   return -EPROBE_DEFER;
  
  
  If nobody else has objections over using of_graph functions instead
  of phandles, I can respin this patchset by making use of video ports.
  
  The discussion did digress somewhat.
  
  As a clarification, I'm in no way nack'ing this series because it
  doesn't use the graphs for video connections. I don't see the simple
  phandle bindings used here as broken as such.
 
 Well, I am okay with any approach you guys decide on. I desperately want
 this to get this in since it has been floating around for quite sometime.
 The more we drag this, the more rework for me since the number of platforms
 using bridge support is increasing daily!

I won't nack this patch either. I'm however concerned that we'll run straight 
into the wall if we don't come up with an agreement on a standard way to 
describe connections in DT for display devices, which is why I would prefer 
the ps8622 bindings to use OF graph to describe connections.

-- 
Regards,

Laurent Pinchart

--
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] drm/exynos: vidi: fix build warning

2014-10-07 Thread Inki Dae
encoder object isn't used anymore so remove it.

Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 9395e85..50faf91 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -630,7 +630,6 @@ static int vidi_remove(struct platform_device *pdev)
 {
struct exynos_drm_manager *mgr = platform_get_drvdata(pdev);
struct vidi_context *ctx = mgr-ctx;
-   struct drm_encoder *encoder = ctx-encoder;
 
if (ctx-raw_edid != (struct edid *)fake_edid_info) {
kfree(ctx-raw_edid);
-- 
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] drm/exynos: init vblank with real number of crtcs

2014-10-07 Thread Inki Dae

Sorry for late.

On 2014년 10월 07일 21:27, Andrzej Hajda wrote:
 Hi Inki,
 
 Gently ping.
 
 Andrzej
 
 
 On 09/19/2014 02:57 PM, Andrzej Hajda wrote:
 Initialization of vblank with MAX_CRTC caused attempts
 to disabling vblanks for non-existing crtcs in case
 drm used fewer crtcs. The patch fixes it.

Nice catch~ This patch also resolves unbind issue. When exynos driver is
unbound, disable_vblank callback is called as dev-num_crtcs so if the
number of probed crtc drivers is different from the one of enabled crtc
drivers then it could attempt to disabling vblank for non-existing crtc,
which in turn, null pointer access occurs.

Thanks,
Inki Dae


 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index 9b00e4e..dc4affd 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, 
 unsigned long flags)
  /* init kms poll for handling hpd */
  drm_kms_helper_poll_init(dev);
  
 -ret = drm_vblank_init(dev, MAX_CRTC);
 -if (ret)
 -goto err_mode_config_cleanup;
 -
  /* setup possible_clones. */
  exynos_drm_encoder_setup(dev);
  
 @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, 
 unsigned long flags)
  /* Try to bind all sub drivers. */
  ret = component_bind_all(dev-dev, dev);
  if (ret)
 -goto err_cleanup_vblank;
 +goto err_mode_config_cleanup;
 +
 +ret = drm_vblank_init(dev, dev-mode_config.num_crtc);
 +if (ret)
 +goto err_unbind_all;
  
  /* Probe non kms sub drivers and virtual display driver. */
  ret = exynos_drm_device_subdrv_probe(dev);
  if (ret)
 -goto err_unbind_all;
 +goto err_cleanup_vblank;
  
  /* force connectors detection */
  drm_helper_hpd_irq_event(dev);
  
  return 0;
  
 -err_unbind_all:
 -component_unbind_all(dev-dev, dev);
  err_cleanup_vblank:
  drm_vblank_cleanup(dev);
 +err_unbind_all:
 +component_unbind_all(dev-dev, dev);
  err_mode_config_cleanup:
  drm_mode_config_cleanup(dev);
  drm_release_iommu_mapping(dev);
 @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev)
  exynos_drm_fbdev_fini(dev);
  drm_kms_helper_poll_fini(dev);
  
 -component_unbind_all(dev-dev, dev);
  drm_vblank_cleanup(dev);
 +component_unbind_all(dev-dev, dev);
  drm_mode_config_cleanup(dev);
  drm_release_iommu_mapping(dev);
  

 
 

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-10-07 Thread Laurent Pinchart
Hi Tomi,

On Tuesday 07 October 2014 11:25:56 Tomi Valkeinen wrote:
 On 07/10/14 10:23, Laurent Pinchart wrote:
  You mean the bridge driver would somehow take a peek into panel1 and
  panel2 nodes, looking for bridge specific properties? Sounds somewhat
  fragile to me... How would the bridge driver know a property is for the
  bridge?
  
  No, I mean the bridge driver should call the API provided by the panel
  objects to get information about the panels, and compute its
  configuration parameters from those. I'm not sure if that's possible
  though, it depends on whether the bridge parameters can be computed from
  information provided by the panel.

 Right. My example tried to show a case where they can't be queried. The
 board or the wiring causes signal degradation, which can be fixed by
 increasing the bridge output voltage slightly.
 
 So it has nothing really to do with the panel, but the board.
 
 I fully admit that it is a purely theoretical case, and I don't have any
 real use cases in mind right now.

Still, I agree with you that we might need to configure the bridge differently 
depending on the selected output with parameters that are not specific to the 
bridge.

There's two use cases I can think of. In the first one the panels are 
connected directly to the bridge. The bridge should have two links from its 
output port, one to each panel. If we use the OF graph bindings then the 
bridge output port node would have two endpoint nodes, and configuration 
parameters can be stored in the endpoint nodes.

In the second use case another element would be present between the bridge and 
the two panels. In that case there would be a single link between the bridge 
and that other element. If the bridge needs to be configured differently 
depending on the selected panel using parameters that can't be queried from 
the panels, then we'll have a problem. I'm not sure whether this use case has 
practical applications as board-related parameters seem to me that they 
pertain to physical links.

-- 
Regards,

Laurent Pinchart

--
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 0/2] Handle reboot for Exynos SoC via restart_handler

2014-10-07 Thread Guenter Roeck
On Tue, Oct 07, 2014 at 01:23:19PM +0530, Pankaj Dubey wrote:
 This patch removes restart hook from machine_desc of Exynos, and moves
 respective code into reboot_notifiers.

Nitpick:

s/reboot_notifiers/restart_notifiers/

Guenter

 Exynos5440 handles reboot via clock register so let's register a
 restart_handler in Exynos5440 clock driver.
 For rest Exynos SoC, reboot is handled via PMU SWRESET register so
 let's register a restart_handler in PMU driver for handling this.
 
 This patch is inspired and dependent on following patch series[1] from
 Geunter Roeck.
 
 Also this patch is dependent on PMU platform driver patch [2] by me, and
 has been prepared on top of it.
 
 [1]: kernel: Add support for kernel restart handler call chain
 https://lkml.org/lkml/2014/8/19/652
 
 [2]: ARM: Exynos: Convert PMU implementation into a platform driver
 https://lkml.org/lkml/2014/10/6/89
 
 I have tested reboot functionality on Exynos3250 based board, on
 kgene/for-next as well as linux-next's next-20140925 tag.
 
 Patch v2 and related discussion can be found here
 http://www.spinics.net/lists/linux-samsung-soc/msg37457.html
 
 Changes since v2:
   - Used register_restart_handler instead of register_reboot_notifier.
   - Updated notifier names and commit message accordingly.
 
 Changes since v1:
   - Addressed review comments from Tomasz Figa. Removed usage of 
 local variables where ever unnecessary.
   - Make reg_base as global in clk-exynos5440.c file, to avoid 
 iomapping it again in reboot_notifier handler.
 
 Pankaj Dubey (2):
   clk: samsung: exynos5440: move restart code into clock driver
   ARM: EXYNOS: PMU: move restart code into pmu driver
 
  arch/arm/mach-exynos/common.h|1 -
  arch/arm/mach-exynos/exynos.c|   23 ---
  arch/arm/mach-exynos/pmu.c   |   24 
  drivers/clk/samsung/clk-exynos5440.c |   29 -
  4 files changed, 52 insertions(+), 25 deletions(-)
 
 -- 
 1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCHv2 0/2] ARM: dts: Add new board dts file for Exynos3250-based Rinato board

2014-10-07 Thread Chanwoo Choi
This patchset adds new board dts file for Samsung Rinato board (Gear 2) which
is based on Exynos3250 SoC and adds sleep mode pin configuration using pinctrl
subsystem to reduce leakage power-consumption in sleep state.

This patchset is based on linux-samsung.git (for-next branch).

Changes from v1:
- Remove useless brace
- Remove unneeded 'regulators' keyword
- Consolidate memory information in one entry

Chanwoo Choi (2):
  ARM: dts: Add board dts file for Exynos3250-based Rinato board
  ARM: dts: Add sleep mode pin configuration for exynos3250-rinato

 arch/arm/boot/dts/Makefile|   3 +-
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi |  16 +
 arch/arm/boot/dts/exynos3250-rinato.dts   | 586 ++
 3 files changed, 604 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/exynos3250-rinato.dts

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


[PATCHv2 2/2] ARM: dts: Add sleep mode pin configuration for exynos3250-rinato

2014-10-07 Thread Chanwoo Choi
This patch add sleep mode pin configuration using pinctrl subsystem
to reduce leakage power-consumption of gpio pin in sleep state.

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park Kyungmin p...@samsung.com
---
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi |  16 
 arch/arm/boot/dts/exynos3250-rinato.dts   | 154 ++
 2 files changed, 170 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
index 47b92c1..5ab81c3 100644
--- a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -12,6 +12,22 @@
  * published by the Free Software Foundation.
 */
 
+#define PIN_PULL_NONE  0
+#define PIN_PULL_DOWN  1
+#define PIN_PULL_UP3
+
+#define PIN_PDN_OUT0   0
+#define PIN_PDN_OUT1   1
+#define PIN_PDN_INPUT  2
+#define PIN_PDN_PREV   3
+
+#define PIN_SLP(_pin, _mode, _pull)\
+   _pin {  \
+   samsung,pins = #_pin;   \
+   samsung,pin-con-pdn = PIN_PDN_ ##_mode;   \
+   samsung,pin-pud-pdn = PIN_PULL_ ##_pull;  \
+   }
+
 pinctrl_0 {
gpa0: gpa0 {
gpio-controller;
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index af75ed7..63861e7 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -430,3 +430,157 @@
 xusbxti {
clock-frequency = 2400;
 };
+
+pinctrl_0 {
+   pinctrl-names = default;
+   pinctrl-0 = sleep0;
+
+   sleep0: sleep-state {
+   PIN_SLP(gpa0-0, INPUT, DOWN);
+   PIN_SLP(gpa0-1, INPUT, DOWN);
+   PIN_SLP(gpa0-2, INPUT, DOWN);
+   PIN_SLP(gpa0-3, INPUT, DOWN);
+   PIN_SLP(gpa0-4, INPUT, DOWN);
+   PIN_SLP(gpa0-5, INPUT, DOWN);
+   PIN_SLP(gpa0-6, INPUT, DOWN);
+   PIN_SLP(gpa0-7, INPUT, DOWN);
+
+   PIN_SLP(gpa1-0, INPUT, DOWN);
+   PIN_SLP(gpa1-1, INPUT, DOWN);
+   PIN_SLP(gpa1-2, INPUT, DOWN);
+   PIN_SLP(gpa1-3, INPUT, DOWN);
+   PIN_SLP(gpa1-4, INPUT, DOWN);
+   PIN_SLP(gpa1-5, INPUT, DOWN);
+
+   PIN_SLP(gpb-0, PREV, NONE);
+   PIN_SLP(gpb-1, PREV, NONE);
+   PIN_SLP(gpb-2, PREV, NONE);
+   PIN_SLP(gpb-3, PREV, NONE);
+   PIN_SLP(gpb-4, INPUT, DOWN);
+   PIN_SLP(gpb-5, INPUT, DOWN);
+   PIN_SLP(gpb-6, INPUT, DOWN);
+   PIN_SLP(gpb-7, INPUT, DOWN);
+
+   PIN_SLP(gpc0-0, INPUT, DOWN);
+   PIN_SLP(gpc0-1, INPUT, DOWN);
+   PIN_SLP(gpc0-2, INPUT, DOWN);
+   PIN_SLP(gpc0-3, INPUT, DOWN);
+   PIN_SLP(gpc0-4, INPUT, DOWN);
+
+   PIN_SLP(gpc1-0, INPUT, DOWN);
+   PIN_SLP(gpc1-1, INPUT, DOWN);
+   PIN_SLP(gpc1-2, INPUT, DOWN);
+   PIN_SLP(gpc1-3, INPUT, DOWN);
+   PIN_SLP(gpc1-4, INPUT, DOWN);
+
+   PIN_SLP(gpd0-0, INPUT, DOWN);
+   PIN_SLP(gpd0-1, INPUT, DOWN);
+   PIN_SLP(gpd0-2, INPUT, NONE);
+   PIN_SLP(gpd0-3, INPUT, NONE);
+
+   PIN_SLP(gpd1-0, INPUT, NONE);
+   PIN_SLP(gpd1-1, INPUT, NONE);
+   PIN_SLP(gpd1-2, INPUT, NONE);
+   PIN_SLP(gpd1-3, INPUT, NONE);
+   };
+};
+
+pinctrl_1 {
+   pinctrl-names = default;
+   pinctrl-0 = sleep1;
+
+   sleep1: sleep-state {
+   PIN_SLP(gpe0-0, PREV, NONE);
+   PIN_SLP(gpe0-1, PREV, NONE);
+   PIN_SLP(gpe0-2, INPUT, DOWN);
+   PIN_SLP(gpe0-3, INPUT, DOWN);
+   PIN_SLP(gpe0-4, INPUT, DOWN);
+   PIN_SLP(gpe0-5, INPUT, DOWN);
+   PIN_SLP(gpe0-6, INPUT, DOWN);
+   PIN_SLP(gpe0-7, INPUT, DOWN);
+
+   PIN_SLP(gpe1-0, INPUT, DOWN);
+   PIN_SLP(gpe1-1, PREV, NONE);
+   PIN_SLP(gpe1-2, INPUT, DOWN);
+   PIN_SLP(gpe1-3, INPUT, DOWN);
+   PIN_SLP(gpe1-4, INPUT, DOWN);
+   PIN_SLP(gpe1-5, INPUT, DOWN);
+   PIN_SLP(gpe1-6, INPUT, DOWN);
+   PIN_SLP(gpe1-7, INPUT, NONE);
+
+   PIN_SLP(gpe2-0, INPUT, NONE);
+   PIN_SLP(gpe2-1, INPUT, NONE);
+   PIN_SLP(gpe2-2, INPUT, NONE);
+
+   PIN_SLP(gpk0-0, INPUT, DOWN);
+   PIN_SLP(gpk0-1, INPUT, DOWN);
+   PIN_SLP(gpk0-2, OUT0, NONE);
+   PIN_SLP(gpk0-3, INPUT, DOWN);
+   PIN_SLP(gpk0-4, INPUT, DOWN);
+   PIN_SLP(gpk0-5, INPUT, DOWN);
+   PIN_SLP(gpk0-6, INPUT, DOWN);
+   PIN_SLP(gpk0-7, INPUT, DOWN);
+
+   PIN_SLP(gpk1-0, 

[PATCHv2 1/2] ARM: dts: Add board dts file for Exynos3250-based Rinato board

2014-10-07 Thread Chanwoo Choi
This patch add support for device tree sources for Samsung Rinato baord
(Gear 2) based on Exynos3250 SoC.

This dts file support following features:
- eMMC
- Main PMIC (Samsung S2MPS14)
- Interface PMIC (Maxim MAX77836, MUIC, fuel-gauge, charger)
- RTC of Exynos3250
- ADC of Exynos3250 with NTC thermistor
- I2S of Exynos3250
- TMU of Exynos3250
- MFC of Exynos3250
- Secure firmware for Exynos3250 secondary cpu boot
- Serial ports of Exynos3250
- gpio-key for power key

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/boot/dts/Makefile  |   3 +-
 arch/arm/boot/dts/exynos3250-rinato.dts | 432 
 2 files changed, 434 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/exynos3250-rinato.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b4f1fb1..5728918 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -64,7 +64,8 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
 dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
-dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-rinato.dtb \
+   exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
exynos4210-universal_c210.dtb \
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
new file mode 100644
index 000..af75ed7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -0,0 +1,432 @@
+/*
+ * Samsung's Exynos3250 based Rinato board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Rinato board which is based on
+ * Samsung Exynos3250 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos3250.dtsi
+#include dt-bindings/input/input.h
+
+/ {
+   model = Samsung Rinato board;
+   compatible = samsung,rinato, samsung,exynos3250, samsung,exynos3;
+
+   aliases {
+   i2c7 = i2c_max77836;
+   };
+
+   memory {
+   reg =  0x4000 0x1ff0;
+   };
+
+   chosen {
+   bootargs = console=ttySAC1,115200N8 root=/dev/mmcblk0p15 
rootwait earlyprintk panic=5;
+   };
+
+   firmware@0205F000 {
+   compatible = samsung,secure-firmware;
+   reg = 0x0205F000 0x1000;
+   };
+
+   gpio_keys {
+   compatible = gpio-keys;
+
+   power_key {
+   interrupt-parent = gpx2;
+   interrupts = 7 0;
+   gpios = gpx2 7 1;
+   linux,code = KEY_POWER;
+   label = power key;
+   debounce-interval = 10;
+   gpio-key,wakeup;
+   };
+   };
+
+   vemmc_reg: voltage-regulator-0 {
+   compatible = regulator-fixed;
+   regulator-name = V_EMMC_2.8V-fixed;
+   regulator-min-microvolt = 280;
+   regulator-max-microvolt = 280;
+   gpio = gpk0 2 0;
+   enable-active-high;
+   };
+
+   i2c_max77836: i2c-gpio-0 {
+   compatible = i2c-gpio;
+   gpios = gpd0 2 0, gpd0 3 0;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   max77836: subpmic@25 {
+   compatible = maxim,max77836;
+   interrupt-parent = gpx1;
+   interrupts = 5 0;
+   reg = 0x25;
+   wakeup;
+
+   muic: max77836-muic {
+   compatible = maxim,max77836-muic;
+   };
+
+   regulators {
+   compatible = maxim,max77836-regulator;
+   safeout_reg: SAFEOUT {
+   regulator-name = SAFEOUT;
+   };
+
+   charger_reg: CHARGER {
+   regulator-name = CHARGER;
+   regulator-min-microamp = 45000;
+   regulator-max-microamp = 475000;
+   regulator-boot-on;
+   };
+
+   motor_reg: LDO1 {
+   regulator-name = MOT_2.7V;
+   

Re: [PATCH] ARM: dts: fix MMC2 regulators for Exynos5420 Arndale Octa board

2014-10-07 Thread Jaehoon Chung
Hi,

On 10/07/2014 01:51 AM, Doug Anderson wrote:
 Bartlomiej,
 
 On Thu, Oct 2, 2014 at 10:24 AM, Bartlomiej Zolnierkiewicz
 b.zolnier...@samsung.com wrote:

 Hi,

 On Thursday, October 02, 2014 09:45:41 AM Doug Anderson wrote:
 Bartiomiej

 On Thu, Oct 2, 2014 at 9:39 AM, Bartlomiej Zolnierkiewicz
 b.zolnier...@samsung.com wrote:
 On Thursday, October 02, 2014 09:19:08 AM Doug Anderson wrote:
 Bartiomiej,

 On Thu, Oct 2, 2014 at 9:10 AM, Bartlomiej Zolnierkiewicz
 b.zolnier...@samsung.com wrote:
 Regulators for MMC2 (SD card) are PVDD_TFLASH_2V8 (LDO19) for vmmc
 and PVDD_APIO_MMCOFF_2V8 (LDO13) for vqmmc.  Currently the device
 tree entry for MMC2 uses PVDD_PRE_1V8 (LDO10) for vmmc and vqmmc is
 not specified.  Fix it.

 Without this patch:
 - mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
   patch causes a SD card detection to fail
 - mmc: dw_mmc: Support voltage changes patch causes a boot hang

 This patch fixes both above problems.

 Suggested-by: Doug Anderson diand...@google.com
 Cc: Yuvaraj Kumar C D yuvaraj...@samsung.com
 Cc: Ulf Hansson ulf.hans...@linaro.org
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/boot/dts/exynos5420-arndale-octa.dts |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 Index: b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
 ===
 --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 
 15:44:53.014826886 +0200
 +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts 2014-10-02 
 17:35:24.110600398 +0200
 @@ -74,7 +74,8 @@
 samsung,dw-mshc-ddr-timing = 1 2;
 pinctrl-names = default;
 pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
 -   vmmc-supply = ldo10_reg;
 +   vmmc-supply = ldo19_reg;
 +   vqmmc-supply = ldo13_reg;

 This looks right to me.  ...but I notice that ldo13 and ldo19 are not
 always-on in the DTS.  Are you sure card detect works for you if you
 eject your card and try to put it back in?

 ...eventually the always-on won't be needed, but for now I think it 
 is...

 Card detection works fine without always-on.

 That's weird.

 1. In the schematics I see XMMC2CDN has an external pullup to 
 PVDD_TFLASH_2V8.

 2. The internal pullup should (I think) be to VDDQ_MMC2 which is
 PVDD_APIO_MMCOFF_2V8.

 3. In (51da224 mmc: dw_mmc: use mmc_regulator_get_supply to handle
 regulators) we should be turning off both regulators in
 MMC_POWER_OFF.

 4. If I understand correctly MMC_POWER_OFF is called when the card is
 ejected, which means that both regulators should be off when the card
 is ejected.

 5. I don't think card detect can work if neither regulator is powered.


 One of the above points must be wrong.  Any idea which one?  Can you
 check to see if MMC_POWER_OFF is called for you when the card is
 ejected?  Can you check to see if these regulators are off?

 MMC_POWER_OFF is called on card removal and both regulators get disabled
 (I have verified that they are really off with regulator_is_enabled() which
 returns 1 before and 0 after disabling regulator).  It seems that 5. is
 wrong?
 
 This really doesn't make a lot of sense to me, so I'm still kinda
 confused.  If you want to call it good then that's your (and Ulf's)
 decision, but it's the kind of thing that would keep me up at night.
 How can this pin be high if all the regulators pulling it up are off?
 Is there a current leak somewhere and that's why it's working?
 
 How this is supposed to work (as I understand it):
 
 1. When no card is inserted then this pin is supposed to be pulled up
 to VDDQ_MMC2.  That could be either an internal or an external pullup.
 It should be pulled up to VDDQ_MMC2 (as opposed to any other voltage)
 since the exynos manual documents that this pin lives in the VDDQ_MMC2
 io domain.  Note that it could be pulled up externally to a different
 supply than the one going to VDDQ_MMC2, but for correctness it should
 be the same voltage.
 
 2. When a card is inserted, the pin will be grounded (AKA this is an
 open drain pin).
 
 
 With your patch, can you probe the pin and see if card detect is high
 when all the regulators are off?  Any idea how it gets high?  If you
 turn off the internal pullup is it still high?

I remembered that I and Doug were discussed for this problem with 
exynos5420-peach board(?), right?
Is arndale-octa board the same circuit with peach?
If it's same, I think Doug's comment is right.
But if card-detect pis is used with other power, we don't need to consider the 
VDDQ_MMC2 power domain.
It needs more information and checks its schematic.

Best Regards,
Jaehoon Chung

 
 
 -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] drm/exynos: init vblank with real number of crtcs

2014-10-07 Thread Inki Dae
On 2014년 10월 08일 00:28, Inki Dae wrote:
 
 Sorry for late.
 
 On 2014년 10월 07일 21:27, Andrzej Hajda wrote:
 Hi Inki,

 Gently ping.

 Andrzej


 On 09/19/2014 02:57 PM, Andrzej Hajda wrote:
 Initialization of vblank with MAX_CRTC caused attempts
 to disabling vblanks for non-existing crtcs in case
 drm used fewer crtcs. The patch fixes it.
 
 Nice catch~ This patch also resolves unbind issue. When exynos driver is
 unbound, disable_vblank callback is called as dev-num_crtcs so if the
 number of probed crtc drivers is different from the one of enabled crtc

Oops, s/the one of enabled crtc drivers/MAX_CRTC

 drivers then it could attempt to disabling vblank for non-existing crtc,
 which in turn, null pointer access occurs.
 
 Thanks,
 Inki Dae
 

 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index 9b00e4e..dc4affd 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, 
 unsigned long flags)
 /* init kms poll for handling hpd */
 drm_kms_helper_poll_init(dev);
  
 -   ret = drm_vblank_init(dev, MAX_CRTC);
 -   if (ret)
 -   goto err_mode_config_cleanup;
 -
 /* setup possible_clones. */
 exynos_drm_encoder_setup(dev);
  
 @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, 
 unsigned long flags)
 /* Try to bind all sub drivers. */
 ret = component_bind_all(dev-dev, dev);
 if (ret)
 -   goto err_cleanup_vblank;
 +   goto err_mode_config_cleanup;
 +
 +   ret = drm_vblank_init(dev, dev-mode_config.num_crtc);
 +   if (ret)
 +   goto err_unbind_all;
  
 /* Probe non kms sub drivers and virtual display driver. */
 ret = exynos_drm_device_subdrv_probe(dev);
 if (ret)
 -   goto err_unbind_all;
 +   goto err_cleanup_vblank;
  
 /* force connectors detection */
 drm_helper_hpd_irq_event(dev);
  
 return 0;
  
 -err_unbind_all:
 -   component_unbind_all(dev-dev, dev);
  err_cleanup_vblank:
 drm_vblank_cleanup(dev);
 +err_unbind_all:
 +   component_unbind_all(dev-dev, dev);
  err_mode_config_cleanup:
 drm_mode_config_cleanup(dev);
 drm_release_iommu_mapping(dev);
 @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev)
 exynos_drm_fbdev_fini(dev);
 drm_kms_helper_poll_fini(dev);
  
 -   component_unbind_all(dev-dev, dev);
 drm_vblank_cleanup(dev);
 +   component_unbind_all(dev-dev, dev);
 drm_mode_config_cleanup(dev);
 drm_release_iommu_mapping(dev);
  



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

--
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 v2] ARM: dts: add board dts file for Exynos3250-based Monk board

2014-10-07 Thread YoungJun Cho
From: Youngjun Cho yj44@samsung.com

This patch adds new board dts file to support Samsung Monk board which is
based on Exynos3250 SoC and has different H/W configuration from Rinato.

This patch is based on linux-samsung.git for-next branch and depends on
[PATCHv2 0/2] ARM: dts: Add new board dts file for Exynos3250-based Rinato board

Changes from v1:
- The 'memory' entries coalesce into one entry
- Removes useless space
- Puts voltage-regulator-0 under the root node

This dts file support following features:
- eMMC
- Main PMIC (Samsung S2MPS14)
- Interface PMIC (Maxim MAX77836, MUIC, fuel-gauge, charger)
- RTC of Exynos3250
- ADC of Exynos3250 with NTC thermistor
- I2S of Exynos3250
- TMU of Exynos3250
- Secure firmware for Exynos3250 secondary cpu boot
- Serial ports of Exynos3250
- gpio-key for power key

Signed-off-by: Youngjun Cho yj44@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/boot/dts/Makefile|   3 +-
 arch/arm/boot/dts/exynos3250-monk.dts | 583 ++
 2 files changed, 585 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/exynos3250-monk.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5728918..0c8ae64 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -64,7 +64,8 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
 dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
-dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-rinato.dtb \
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-monk.dtb \
+   exynos3250-rinato.dtb \
exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
new file mode 100644
index 000..615672f
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -0,0 +1,583 @@
+/*
+ * Samsung's Exynos3250 based Monk board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Monk board which is based on
+ * Samsung Exynos3250 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos3250.dtsi
+#include dt-bindings/input/input.h
+
+/ {
+   model = Samsung Monk board;
+   compatible = samsung,monk, samsung,exynos3250, samsung,exynos3;
+
+   aliases {
+   i2c7 = i2c_max77836;
+   };
+
+   memory {
+   reg =  0x4000 0x1ff0;
+   };
+
+   chosen {
+   bootargs = console=ttySAC1,115200N8 root=/dev/mmcblk0p15 
rootwait earlyprintk panic=5;
+   };
+
+   firmware@0205F000 {
+   compatible = samsung,secure-firmware;
+   reg = 0x0205F000 0x1000;
+   };
+
+   gpio_keys {
+   compatible = gpio-keys;
+
+   power_key {
+   interrupt-parent = gpx2;
+   interrupts = 7 0;
+   gpios = gpx2 7 1;
+   linux,code = KEY_POWER;
+   label = power key;
+   debounce-interval = 10;
+   gpio-key,wakeup;
+   };
+   };
+
+   vemmc_reg: voltage-regulator-0 {
+   compatible = regulator-fixed;
+   regulator-name = V_EMMC_2.8V-fixed;
+   regulator-min-microvolt = 280;
+   regulator-max-microvolt = 280;
+   gpio = gpk0 2 0;
+   enable-active-high;
+   };
+
+   i2c_max77836: i2c-gpio-0 {
+   compatible = i2c-gpio;
+   gpios = gpd0 2 0, gpd0 3 0;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   max77836: subpmic@25 {
+   compatible = maxim,max77836;
+   interrupt-parent = gpx1;
+   interrupts = 5 0;
+   reg = 0x25;
+   wakeup;
+
+   muic: max77836-muic {
+   compatible = maxim,max77836-muic;
+   };
+
+   regulators {
+   compatible = maxim,max77836-regulator;
+   safeout_reg: SAFEOUT {
+   regulator-name = SAFEOUT;
+   };
+
+   charger_reg: CHARGER {
+   regulator-name = CHARGER;
+   

Re: [PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

2014-10-07 Thread Vivek Gautam
Hi,


On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
 Now that we have moved to generic phy based bindings,
 we don't need to have any code related to older dptx-phy.
 Nobody is using this dptx-phy anymore, so removing the
 same.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com
 ---

Is someone taking care of this patch ? We already have got the corresponsding
dp-phy patch merged, so we should also get this patch in.

  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
 +++
  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
  2 files changed, 13 insertions(+), 47 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index 4f3c7eb..5ffc1b2 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
 exynos_drm_display *display,

  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
  {
 -   if (dp-phy) {
 +   if (dp-phy)
 phy_power_on(dp-phy);
 -   } else if (dp-phy_addr) {
 -   u32 reg;
 -
 -   reg = __raw_readl(dp-phy_addr);
 -   reg |= dp-enable_mask;
 -   __raw_writel(reg, dp-phy_addr);
 -   }
  }

  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
  {
 -   if (dp-phy) {
 +   if (dp-phy)
 phy_power_off(dp-phy);
 -   } else if (dp-phy_addr) {
 -   u32 reg;
 -
 -   reg = __raw_readl(dp-phy_addr);
 -   reg = ~(dp-enable_mask);
 -   __raw_writel(reg, dp-phy_addr);
 -   }
  }

  static void exynos_dp_poweron(struct exynos_drm_display *display)
 @@ -1210,39 +1196,21 @@ static struct video_info 
 *exynos_dp_dt_parse_pdata(struct device *dev)

  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
  {
 -   struct device_node *dp_phy_node = of_node_get(dp-dev-of_node);
 -   u32 phy_base;
 int ret = 0;

 -   dp_phy_node = of_find_node_by_name(dp_phy_node, dptx-phy);
 -   if (!dp_phy_node) {
 -   dp-phy = devm_phy_get(dp-dev, dp);
 -   return PTR_ERR_OR_ZERO(dp-phy);
 -   }
 -
 -   if (of_property_read_u32(dp_phy_node, reg, phy_base)) {
 -   dev_err(dp-dev, failed to get reg for dptx-phy\n);
 -   ret = -EINVAL;
 -   goto err;
 -   }
 -
 -   if (of_property_read_u32(dp_phy_node, samsung,enable-mask,
 -   dp-enable_mask)) {
 -   dev_err(dp-dev, failed to get enable-mask for dptx-phy\n);
 -   ret = -EINVAL;
 -   goto err;
 -   }
 -
 -   dp-phy_addr = ioremap(phy_base, SZ_4);
 -   if (!dp-phy_addr) {
 -   dev_err(dp-dev, failed to ioremap dp-phy\n);
 -   ret = -ENOMEM;
 -   goto err;
 +   dp-phy = devm_phy_get(dp-dev, dp);
 +   if (IS_ERR(dp-phy)) {
 +   ret = PTR_ERR(dp-phy);
 +   if (ret == -ENOSYS || ret == -ENODEV) {
 +   dp-phy = NULL;
 +   } else if (ret == -EPROBE_DEFER) {
 +   return ret;
 +   } else {
 +   dev_err(dp-dev, no DP phy configured\n);
 +   return ret;
 +   }
 }

 -err:
 -   of_node_put(dp_phy_node);
 -
 return ret;
  }

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
 b/drivers/gpu/drm/exynos/exynos_dp_core.h
 index a1aee69..6426201 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
 @@ -153,8 +153,6 @@ struct exynos_dp_device {
 struct clk  *clock;
 unsigned intirq;
 void __iomem*reg_base;
 -   void __iomem*phy_addr;
 -   unsigned intenable_mask;

 struct video_info   *video_info;
 struct link_train   link_train;
 --
 1.7.10.4




-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

2014-10-07 Thread Vivek Gautam
Hi,

CC'ing Kukjin,
my bad, missed him while sending the patch. :-(

On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
 DP PHY now require pmu-system-controller to handle PMU register
 to control PHY's power isolation. Adding the same to dp-phy
 node.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com
 ---

Is someone taking care of this patch ? We already have got the corresponsding
dp-phy patch merged, so we should also get this patch in.

  arch/arm/boot/dts/exynos5250.dtsi |2 +-
  arch/arm/boot/dts/exynos5420.dtsi |4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
 b/arch/arm/boot/dts/exynos5250.dtsi
 index f21b9aa..9b85a2b 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -732,7 +732,7 @@

 dp_phy: video-phy@10040720 {
 compatible = samsung,exynos5250-dp-video-phy;
 -   reg = 0x10040720 4;
 +   samsung,pmu-syscon = pmu_system_controller;
 #phy-cells = 0;
 };

 diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
 b/arch/arm/boot/dts/exynos5420.dtsi
 index bfe056d..a677812 100644
 --- a/arch/arm/boot/dts/exynos5420.dtsi
 +++ b/arch/arm/boot/dts/exynos5420.dtsi
 @@ -503,8 +503,8 @@
 };

 dp_phy: video-phy@10040728 {
 -   compatible = samsung,exynos5250-dp-video-phy;
 -   reg = 0x10040728 4;
 +   compatible = samsung,exynos5420-dp-video-phy;
 +   samsung,pmu-syscon = pmu_system_controller;
 #phy-cells = 0;
 };

 --
 1.7.10.4




-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

2014-10-07 Thread Vivek Gautam
Hi,


CC'ing Kukjin,
my bad, missed him while sending the patch. :-(

On Wed, Oct 8, 2014 at 8:27 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
 Hi,


 On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
 Now that we have moved to generic phy based bindings,
 we don't need to have any code related to older dptx-phy.
 Nobody is using this dptx-phy anymore, so removing the
 same.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com
 ---

 Is someone taking care of this patch ? We already have got the corresponsding
 dp-phy patch merged, so we should also get this patch in.

  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
 +++
  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
  2 files changed, 13 insertions(+), 47 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index 4f3c7eb..5ffc1b2 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
 exynos_drm_display *display,

  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
  {
 -   if (dp-phy) {
 +   if (dp-phy)
 phy_power_on(dp-phy);
 -   } else if (dp-phy_addr) {
 -   u32 reg;
 -
 -   reg = __raw_readl(dp-phy_addr);
 -   reg |= dp-enable_mask;
 -   __raw_writel(reg, dp-phy_addr);
 -   }
  }

  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
  {
 -   if (dp-phy) {
 +   if (dp-phy)
 phy_power_off(dp-phy);
 -   } else if (dp-phy_addr) {
 -   u32 reg;
 -
 -   reg = __raw_readl(dp-phy_addr);
 -   reg = ~(dp-enable_mask);
 -   __raw_writel(reg, dp-phy_addr);
 -   }
  }

  static void exynos_dp_poweron(struct exynos_drm_display *display)
 @@ -1210,39 +1196,21 @@ static struct video_info 
 *exynos_dp_dt_parse_pdata(struct device *dev)

  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
  {
 -   struct device_node *dp_phy_node = of_node_get(dp-dev-of_node);
 -   u32 phy_base;
 int ret = 0;

 -   dp_phy_node = of_find_node_by_name(dp_phy_node, dptx-phy);
 -   if (!dp_phy_node) {
 -   dp-phy = devm_phy_get(dp-dev, dp);
 -   return PTR_ERR_OR_ZERO(dp-phy);
 -   }
 -
 -   if (of_property_read_u32(dp_phy_node, reg, phy_base)) {
 -   dev_err(dp-dev, failed to get reg for dptx-phy\n);
 -   ret = -EINVAL;
 -   goto err;
 -   }
 -
 -   if (of_property_read_u32(dp_phy_node, samsung,enable-mask,
 -   dp-enable_mask)) {
 -   dev_err(dp-dev, failed to get enable-mask for dptx-phy\n);
 -   ret = -EINVAL;
 -   goto err;
 -   }
 -
 -   dp-phy_addr = ioremap(phy_base, SZ_4);
 -   if (!dp-phy_addr) {
 -   dev_err(dp-dev, failed to ioremap dp-phy\n);
 -   ret = -ENOMEM;
 -   goto err;
 +   dp-phy = devm_phy_get(dp-dev, dp);
 +   if (IS_ERR(dp-phy)) {
 +   ret = PTR_ERR(dp-phy);
 +   if (ret == -ENOSYS || ret == -ENODEV) {
 +   dp-phy = NULL;
 +   } else if (ret == -EPROBE_DEFER) {
 +   return ret;
 +   } else {
 +   dev_err(dp-dev, no DP phy configured\n);
 +   return ret;
 +   }
 }

 -err:
 -   of_node_put(dp_phy_node);
 -
 return ret;
  }

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
 b/drivers/gpu/drm/exynos/exynos_dp_core.h
 index a1aee69..6426201 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
 @@ -153,8 +153,6 @@ struct exynos_dp_device {
 struct clk  *clock;
 unsigned intirq;
 void __iomem*reg_base;
 -   void __iomem*phy_addr;
 -   unsigned intenable_mask;

 struct video_info   *video_info;
 struct link_train   link_train;
 --
 1.7.10.4




 --
 Best Regards
 Vivek Gautam
 Samsung RD Institute, Bangalore
 India



-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-07 Thread Vivek Gautam
On Tue, Oct 7, 2014 at 7:41 PM, Felipe Balbi ba...@ti.com wrote:
 On Tue, Oct 07, 2014 at 03:49:33PM +0530, Vivek Gautam wrote:
 Exynos7 also has a separate special gate clock going to the IP
 apart from the usual AHB clock. So add support for the same.

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

 I'll take this one once -rc1 is tagged. The others have no direct
 dependency on this so I'll leave them to Kishon.

Thanks Felipe !



-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

2014-10-07 Thread Inki Dae
On 2014년 10월 08일 11:57, Vivek Gautam wrote:
 Hi,
 
 
 On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
 Now that we have moved to generic phy based bindings,
 we don't need to have any code related to older dptx-phy.
 Nobody is using this dptx-phy anymore, so removing the
 same.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com
 ---
 
 Is someone taking care of this patch ? We already have got the corresponsding
 dp-phy patch merged, so we should also get this patch in.
 

Can anyone give me tested-by after test? I cannot test this module
because I have no any board equipped with dp panel.

Jingoo or other?

Thanks,
Inki Dae

  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
 +++
  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
  2 files changed, 13 insertions(+), 47 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index 4f3c7eb..5ffc1b2 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
 exynos_drm_display *display,

  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
  {
 -   if (dp-phy) {
 +   if (dp-phy)
 phy_power_on(dp-phy);
 -   } else if (dp-phy_addr) {
 -   u32 reg;
 -
 -   reg = __raw_readl(dp-phy_addr);
 -   reg |= dp-enable_mask;
 -   __raw_writel(reg, dp-phy_addr);
 -   }
  }

  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
  {
 -   if (dp-phy) {
 +   if (dp-phy)
 phy_power_off(dp-phy);
 -   } else if (dp-phy_addr) {
 -   u32 reg;
 -
 -   reg = __raw_readl(dp-phy_addr);
 -   reg = ~(dp-enable_mask);
 -   __raw_writel(reg, dp-phy_addr);
 -   }
  }

  static void exynos_dp_poweron(struct exynos_drm_display *display)
 @@ -1210,39 +1196,21 @@ static struct video_info 
 *exynos_dp_dt_parse_pdata(struct device *dev)

  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
  {
 -   struct device_node *dp_phy_node = of_node_get(dp-dev-of_node);
 -   u32 phy_base;
 int ret = 0;

 -   dp_phy_node = of_find_node_by_name(dp_phy_node, dptx-phy);
 -   if (!dp_phy_node) {
 -   dp-phy = devm_phy_get(dp-dev, dp);
 -   return PTR_ERR_OR_ZERO(dp-phy);
 -   }
 -
 -   if (of_property_read_u32(dp_phy_node, reg, phy_base)) {
 -   dev_err(dp-dev, failed to get reg for dptx-phy\n);
 -   ret = -EINVAL;
 -   goto err;
 -   }
 -
 -   if (of_property_read_u32(dp_phy_node, samsung,enable-mask,
 -   dp-enable_mask)) {
 -   dev_err(dp-dev, failed to get enable-mask for dptx-phy\n);
 -   ret = -EINVAL;
 -   goto err;
 -   }
 -
 -   dp-phy_addr = ioremap(phy_base, SZ_4);
 -   if (!dp-phy_addr) {
 -   dev_err(dp-dev, failed to ioremap dp-phy\n);
 -   ret = -ENOMEM;
 -   goto err;
 +   dp-phy = devm_phy_get(dp-dev, dp);
 +   if (IS_ERR(dp-phy)) {
 +   ret = PTR_ERR(dp-phy);
 +   if (ret == -ENOSYS || ret == -ENODEV) {
 +   dp-phy = NULL;
 +   } else if (ret == -EPROBE_DEFER) {
 +   return ret;
 +   } else {
 +   dev_err(dp-dev, no DP phy configured\n);
 +   return ret;
 +   }
 }

 -err:
 -   of_node_put(dp_phy_node);
 -
 return ret;
  }

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
 b/drivers/gpu/drm/exynos/exynos_dp_core.h
 index a1aee69..6426201 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
 @@ -153,8 +153,6 @@ struct exynos_dp_device {
 struct clk  *clock;
 unsigned intirq;
 void __iomem*reg_base;
 -   void __iomem*phy_addr;
 -   unsigned intenable_mask;

 struct video_info   *video_info;
 struct link_train   link_train;
 --
 1.7.10.4

 
 
 

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


[PATCH v9] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420

2014-10-07 Thread Abhilash Kesavan
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Acked-by: Nicolas Pitre n...@linaro.org
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
Changes in v5:
- Removed the MCPM flags and just used a local flag to
indicate that we are suspending.
Changes in v6:
- Read the SYS_PWR_REG value to decide if we are suspending
the system.
- Restore the SYS_PWR_REG value post-resume.
- Modified the comments to reflect the first change.
Changes in v7:
- Add the suspend check in exynos_cpu_power_down() rather
than the MCPM back-end.
- Clean-up unnecessary changes related to earlier versions.
Changes in v8:
- Rebased on the latest exynos PMU/PM support patches.
Changes in v9:
- Fixed rebasing issues in v8
- Used pmu_raw_readl instead of __raw_readl

This patch is based on kgene's for-next branch.
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next

Here are the dependencies:
1) Decouple syscon interface from platform devices - v7
http://lkml.org/lkml/2014/9/30/156

2) ARM: Exynos: Convert PMU implementation into a platform driver - v9
https://lkml.org/lkml/2014/10/6/89

3) Exynos5420 PMU/S2R Series - v9
http://www.spinics.net/lists/arm-kernel/msg368207.html

 arch/arm/mach-exynos/mcpm-exynos.c |   32 +++
 arch/arm/mach-exynos/platsmp.c |   12 +
 arch/arm/mach-exynos/suspend.c |   49 
 3 files changed, 78 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
b/arch/arm/mach-exynos/mcpm-exynos.c
index dc9a764..b0d3c2e 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
 #include linux/delay.h
 #include linux/io.h
 #include linux/of_address.h
+#include linux/syscore_ops.h
 
 #include asm/cputype.h
 #include asm/cp15.h
@@ -30,6 +31,8 @@
 #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
 #define EXYNOS5420_USE_L2_COMMON_UP_STATE  BIT(30)
 
+static void __iomem *ns_sram_base_addr;
+
 /*
  * The common v7_exit_coherency_flush API could not be used because of the
  * Erratum 799270 workaround. This macro is the same as the common one (in
@@ -318,10 +321,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = 
{
{},
 };
 
+static void exynos_mcpm_setup_entry_point(void)
+{
+   /*
+* U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+* as part of secondary_cpu_start().  Let's redirect it to the
+* mcpm_entry_point(). This is done during both secondary boot-up as
+* well as system resume.
+*/
+   __raw_writel(0xe59f, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+   __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx  r0 */
+   __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+   .resume = exynos_mcpm_setup_entry_point,
+};
+
 static int __init exynos_mcpm_init(void)
 {
struct device_node *node;
-   void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
 
@@ -387,16 +406,9 @@ static int __init exynos_mcpm_init(void)
pmu_raw_writel(value, EXYNOS_COMMON_OPTION(i));
}
 
-   /*
-* U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
-* as part of secondary_cpu_start().  Let's redirect it to the
-* mcpm_entry_point().
-*/
-   __raw_writel(0xe59f, ns_sram_base_addr); /* ldr r0, [pc, #0] */
-   __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx  r0 */
-   __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+   exynos_mcpm_setup_entry_point();
 
-   iounmap(ns_sram_base_addr);
+   register_syscore_ops(exynos_mcpm_syscore_ops);
 
return ret;
 }
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index adb36a8..7a1ebfe 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -126,6 +126,18 @@ static inline void platform_do_lowpower(unsigned int cpu, 
int *spurious)
  */
 void exynos_cpu_power_down(int cpu)
 {
+   if (cpu == 0  (of_machine_is_compatible(samsung,exynos5420) ||
+   of_machine_is_compatible(samsung,exynos5800))) {
+   /*
+* Bypass power down for CPU0 during suspend. Check for
+* the SYS_PWR_REG value to decide if we are suspending
+* the system.
+*/
+   int val = pmu_raw_readl(EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+
+   if 

Re: [PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC

2014-10-07 Thread Abhilash Kesavan
Hi Arnd and Olof,

On Tue, Sep 30, 2014 at 9:20 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
 On Tue, Sep 30, 2014 at 04:15:21PM +0100, Abhilash Kesavan wrote:
 On Tue, Sep 23, 2014 at 2:18 PM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
  This patchset supports the new Exynos7 Samsung SoC based on Cortex-A57.
  Exynos7 is a System-On-Chip (SoC) that is based on 64-bit ARMv8 RISC
  processor.
 
  The following patches are tested based on linux-next tree (20140919).
  https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
 
  Following patches are required for this series:
  1- tty/serial: fix config dependencies for samsung serial
 
  https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36208.html
  2- dts, kbuild: Implement support for dtb vendor subdirs patchset
 http://comments.gmane.org/gmane.linux.kbuild.devel/12131
 
  Thanks for your comments. I have mentioned Robert's patchset as being
  a dependency for my series here.

 Do you have any comments on the arch and dts changes ?

 The arch changes look fine to me (not much in there, just Kconfig,
 defconfig, Makefile). Regarding the dts, I'd like to see some acks from
 the DT or arm-soc maintainers.

 BTW, the arch/arm64/ patches in your series should be merged via the
 arm-soc tree (Arnd/Olof, cc'ing them now).

Do you have any comments on this series ?

Abhilash

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


Re: [PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC

2014-10-07 Thread Abhilash Kesavan
Hi Tomasz,

On Tue, Oct 7, 2014 at 9:46 AM, Kukjin Kim kg...@kernel.org wrote:
 Tomasz Figa wrote:

 On 30.09.2014 17:12, Abhilash Kesavan wrote:
  Hi Tomasz,
 
  On Mon, Sep 22, 2014 at 2:22 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
  Hi Abhilash,
 
  On 22.09.2014 06:47, Abhilash Kesavan wrote:
  Changes since v4:
  - Fixed comments from Tomasz Figa:
- Changed the namespace prefix from exynos to samsung
- Defined bindings to take all input clocks
- Sorted the Kconfig entries alphabetically in clock Makefile
- Used consistent 1 tab line breaks across the clock file
- Statically initialized the samsung_cmu_info struct
  - Enabled exynos7 in the arm64 defconfig as per Catalin Marinas' comment.
  - Added Kukjin Kim's ack along with Thomas Abraham's tested and reviewed 
  tags.
 
 
  The clock patches look good to me, but since they are doing quite a lot
  of code moving I'd prefer to take them through clk tree. Based on the
  fact that there are no code dependencies between clock patches and
  remaining ones and Exynos7 is a new material for 3.18, I'm inclined to
  apply them to my tree if nobody minds.
 
  Will you be picking up the clock changes soon ?

 I'd like to do so. Kukjin, since clock changes are a part of this
 series, might I have your Ack for them to be applied separately?

 Sure, I'm fine so please go ahead with my ack on the changes.

 Acked-by: Kukjin Kim kgene@samsung.com

 Thanks for your asking.

Can you please pick up the clock changes now that Kukjin has ack'ed it.

Thanks,
Abhilash

 - Kukjin

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