[PATCH] usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs

[Vivek Gautam]

On enabling CONFIG_OF_SELFTEST which enables CONFIG_OF_DYNAMIC,
we found out that while getting PHYs for the controller we were
doing an extra of_node_put on the child node in our routines -
exynos_e/ohci_get_phy().
This child is however already put by of_get_next_available_child()
which does a of_node_put() on the prev node. So there's no point
in putting the same node again in our routine.

Reported-by: Daniel Drake dr...@endlessm.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 drivers/usb/host/ehci-exynos.c |1 -
 drivers/usb/host/ohci-exynos.c |1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7189f2e..1b726bf 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -74,7 +74,6 @@ static int exynos_ehci_get_phy(struct device *dev,
 
phy = devm_of_phy_get(dev, child, NULL);
exynos_ehci-phy[phy_number] = phy;
-   of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index d28b658..39f366b 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -63,7 +63,6 @@ static int exynos_ohci_get_phy(struct device *dev,
 
phy = devm_of_phy_get(dev, child, NULL);
exynos_ohci-phy[phy_number] = phy;
-   of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
-- 
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: exynos5420/arndale-octa: imprecise external aborts on exynos_defconfig

[Thomas Abraham]

Hi Bartlomiej,

On Tue, Sep 30, 2014 at 11:47 PM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Wednesday, September 17, 2014 05:39:29 PM Kevin Hilman wrote:
 Thomas Abraham ta.oma...@gmail.com writes:

  On Thu, Sep 11, 2014 at 12:16 AM, Kevin Hilman khil...@kernel.org wrote:
  Tyler Baker tyler.ba...@linaro.org writes:
 
  Exynos5420-based Arndale octa boards have recently started failing boot
  tests due to imprecise external aborts.  This only appears to happen
  when using exynos_defconfig and boots fine with multi_v7_defconfig.  The
  issue seems to be intermittent, so is not reliably reproducable and
  difficult to bisect.  Here are a few boot logs from recent
  mainline/linux-next kernels that are failing:
 
  FYI, I'm seeing the same periodic aborts.  For example, here's my boot
  of next-20140910:
  http://images.armcloud.us/kernel-ci/next/next-20140910/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html
 
  However, my userspace is much simpler and doesn't seem to cause a panic,
  so my boot tests report passing. (I should fixup my scripts so these
  imprecise aborts are reported as a FAIL.)
 
  I'm glad you pointed out that it happens only with exynos_defconfig and
  not multi_v7_defconfig because I noticed that too.  I haven't had the
  time to track it any further than that, so maybe the exynos folks can
  help track it down from here.
 
  Thanks for reporting this,
 
  Kevin
 
  Hi Tyler, Kevin,
 
  From the bootlog you have shared,
 
  [1.060016] CPU4: failed to come online
  [2.070031] CPU5: failed to come online
  [3.080049] CPU6: failed to come online
  [4.090066] CPU7: failed to come online
  [4.090099] Brought up 4 CPUs
  [4.090109] SMP: Total of 4 processors activated.
  [4.090119] CPU: WARNING: CPU(s) started in wrong/inconsistent
  modes (primary CPU mode 0x13)
  [4.090128] CPU: This may indicate a broken bootloader or firmware.
 
  Would it be possible to set max cpus to 1, disable switcher and try

 Which max cpus do you mean?  For NR_CPUS the lower limit is 2.

The maxcpus=1 kernel parameter could be used here. The reason for
trying with this option was to understand the probable location of
this imprecise abort (mcpm init or secondary cpu boot).

Thanks,
Thomas.


  again. I don't have a arndale octa board but I have tested mainline
  kernel with smdk5420 board. It boots all eight CPUs, switcher works
  fine and there are no imprecise aborts seen.

 Sorry for the delay, I'm travelling this week.

 FWIW, the same CPU boot failures you hilight above are happening on
 multi_v7_defconfig[1] which is not getting the imprecise abort.  This is
 only happening on exynos_defconfig[2], so I'm curious why you think the
 switcher or NR_CPUS might be the issues.

 Anyways, I narrowed this down a bit and discovered it's
 CONFIG_EXYNOS5420_MCPM=y that's the root cause.  If I use
 exynos_defconfig and then disable that option, I don't get any more
 imprecise aborts.

 I have exactly the same issue with Exynos5420 Arndale Octa.

 CONFIG_EXYNOS5420_MCPM was enabled by commit fc3791f3a95d
 (ARM: exynos_defconfig: Update exynos_defconfig) which
 get merged into v3.17-rc1.  It seems that this part of
 the patch should be reverted for the final v3.17 kernel.

 Kevin

 [1] 
 http://images.armcloud.us/kernel-ci/mainline/v3.17-rc5-25-g8ba4caf/arm-multi_v7_defconfig/boot-exynos5420-arndale-octa.html
 [2] 
 http://images.armcloud.us/kernel-ci/mainline/v3.17-rc5-25-g8ba4caf/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html

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

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

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

[Javier Martinez Canillas]

Hello Abhilash,

On Mon, Oct 6, 2014 at 5:40 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 Hi Javier,

 [...]

 diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
 index adb36a8..222aa3c 100644
 --- a/arch/arm/mach-exynos/platsmp.c
 +++ b/arch/arm/mach-exynos/platsmp.c
 @@ -137,6 +137,18 @@ void exynos_cpu_power_down(int cpu)
   */
  void exynos_cpu_power_up(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 = __raw_readl(pmu_base_addr +
 +   EXYNOS5_ARM_CORE0_SYS_PWR_REG);
 +   if (!(val  S5P_CORE_LOCAL_PWR_EN))
 +   return;
 +   }
 pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
 EXYNOS_ARM_CORE_CONFIGURATION(cpu));
  }

 The above block of code should be in exynos_cpu_power_down(). Can you
 re-test s2r after modifying it ? I have to convert a __raw_readl to
 pmu_raw_readl in this patch as well. Once Vikas re-works the base s2r
 patch I will re-post a v9.


Thanks, for the information but unfortunately even after this change I
still have the issue reported in [0]. I also removed the lines from
exynos5420_pm_resume() that you asked Vikash [1].

Which __raw_readl() you had to convert? That is only for consistency
right? Since I see that the __raw_readl() calls are using
pmu_base_addr + offset so it seems to be correct.

I'll test again once you both re-spin your patches then.

 Regards,
 Abhilash

Best regards,
Javier

[0]: http://www.spinics.net/lists/arm-kernel/msg367615.html
[1]: http://www.spinics.net/lists/linux-samsung-soc/msg37561.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

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

[Pankaj Dubey]

Hi Lee,

On Tuesday, September 30, 2014 9:39 PM Doug Anderson wrote,
 Subject: Re: [PATCH v7] mfd: syscon: Decouple syscon interface from platform
 devices
 
 Pankaj,
 
 On Tue, Sep 30, 2014 at 1:35 AM, Pankaj Dubey pankaj.du...@samsung.com
 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
  ---
  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(-)
 
 You probably already have enough tags, but just in case.  ;)  On an 
 rk3288-based
 system (this patch backported to 3.14):
 
 Tested-by: Doug Anderson diand...@chromium.org

I think now we can take have this patch in. So will you please take this patch.

Thanks,
Pankaj Dubey

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

[PATCH 0/4] Remove optional dependencies on PLAT_S5P

[Paul Bolle]

Commit d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code)
removed the Kconfig symbol PLAT_S5P. The seven dependencies on that
symbol have evaluated to false since next-20140716 (for linux-next) and
v3.17-rc1 (for mainline). Probably no one noticed because these are all
optional dependencies.

I've mentioned this a few times:
- http://lkml.kernel.org/r/1405505756.4408.24.camel@x220
- http://lkml.kernel.org/r/1409825817.5546.99.camel@x220
- http://lkml.kernel.org/r/1411068565.2017.83.camel@x220

As far as I know no fix for this is pending. So let's remove these
optional dependencies. If it turns out that they should actually be
replaced by another symbol, as was said in a reply to my first message
but never done, this series can be used as a reference for the places
that need fixing.

This series is done on top of next-20141003. It is tested by grepping
the tree only.

Paul Bolle (4):
  [media] Remove optional dependencies on PLAT_S5P
  [media] exynos4-is: Remove optional dependency on PLAT_S5P
  [media] Remove optional dependency on PLAT_S5P
  usb: host: Remove optional dependencies on PLAT_S5P

 drivers/media/platform/Kconfig| 6 +++---
 drivers/media/platform/exynos4-is/Kconfig | 2 +-
 drivers/media/platform/s5p-tv/Kconfig | 2 +-
 drivers/usb/host/Kconfig  | 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

-- 
1.9.3

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

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

[Abhilash Kesavan]

Hi Javier,

On Mon, Oct 6, 2014 at 1:45 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 Hello Abhilash,

 On Mon, Oct 6, 2014 at 5:40 AM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
 Hi Javier,

 [...]

 diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
 index adb36a8..222aa3c 100644
 --- a/arch/arm/mach-exynos/platsmp.c
 +++ b/arch/arm/mach-exynos/platsmp.c
 @@ -137,6 +137,18 @@ void exynos_cpu_power_down(int cpu)
   */
  void exynos_cpu_power_up(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 = __raw_readl(pmu_base_addr +
 +   EXYNOS5_ARM_CORE0_SYS_PWR_REG);
 +   if (!(val  S5P_CORE_LOCAL_PWR_EN))
 +   return;
 +   }
 pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
 EXYNOS_ARM_CORE_CONFIGURATION(cpu));
  }

 The above block of code should be in exynos_cpu_power_down(). Can you
 re-test s2r after modifying it ? I have to convert a __raw_readl to
 pmu_raw_readl in this patch as well. Once Vikas re-works the base s2r
 patch I will re-post a v9.


 Thanks, for the information but unfortunately even after this change I
 still have the issue reported in [0]. I also removed the lines from
 exynos5420_pm_resume() that you asked Vikash [1].

I have just tested this on the 5420 that I have and it resumes fine.
The difference could be in the bootloader we are using. I'll send out
details of my current setup so that you can cross-check if everything
is the same.

 Which __raw_readl() you had to convert? That is only for consistency
 right? Since I see that the __raw_readl() calls are using
 pmu_base_addr + offset so it seems to be correct.

Yes, it is only for consistency. It should not cause any issues if you
leave it as it is.


 I'll test again once you both re-spin your patches then.

OK.

Regards,
Abhilash

 Regards,
 Abhilash

 Best regards,
 Javier

 [0]: http://www.spinics.net/lists/arm-kernel/msg367615.html
 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg37561.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 2/4] [media] exynos4-is: Remove optional dependency on PLAT_S5P

[Paul Bolle]

Commit d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code)
removed the Kconfig symbol PLAT_S5P. Remove an optional dependency on
that symbol from this Kconfig file too.

Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
 drivers/media/platform/exynos4-is/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 77c951237744..775c3278d0eb 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,7 +2,7 @@
 config VIDEO_SAMSUNG_EXYNOS4_IS
bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
-   depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+   depends on (ARCH_EXYNOS || COMPILE_TEST)
depends on OF  COMMON_CLK
help
  Say Y here to enable camera host interface devices for
-- 
1.9.3

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

[PATCH v9 1/2] ARM: EXYNOS: Add platform driver support for Exynos PMU

[Pankaj Dubey]

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

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 46f3c0d..0ca168e 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -24,6 +24,7 @@ menuconfig ARCH_EXYNOS
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
select SRAM
+   select MFD_SYSCON
help
  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
 
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index cfc62e8..1f5aaa7 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
  * http://www.samsung.com/
  *
  * EXYNOS - CPU PMU(Power Management Unit) support
@@ -10,12 +10,26 @@
  */
 
 #include linux/io.h
-#include linux/kernel.h
+#include linux/of.h
+#include linux/platform_device.h
 
 #include common.h
 #include regs-pmu.h
 
-static const struct exynos_pmu_conf *exynos_pmu_config;
+struct exynos_pmu_data {
+   const struct exynos_pmu_conf *pmu_config;
+   const struct exynos_pmu_conf *pmu_config_extra;
+
+   void (*pmu_init)(void);
+   void (*powerdown_conf)(enum sys_powerdown);
+};
+
+struct exynos_pmu_context {
+   struct device *dev;
+   const struct exynos_pmu_data *pmu_data;
+};
+
+static struct exynos_pmu_context *pmu_context;
 
 static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
@@ -336,7 +350,7 @@ static unsigned int const exynos5_list_diable_wfi_wfe[] = {
EXYNOS5_ISP_ARM_OPTION,
 };
 
-static void exynos5_init_pmu(void)
+static void exynos5_powerdown_conf(enum sys_powerdown mode)
 {
unsigned int i;
unsigned int tmp;
@@ -344,7 +358,7 @@ static void exynos5_init_pmu(void)
/*
 * Enable both SC_FEEDBACK and SC_COUNTER
 */
-   for (i = 0 ; i  ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
+   for (i = 0; i  ARRAY_SIZE(exynos5_list_both_cnt_feed); i++) {
tmp = pmu_raw_readl(exynos5_list_both_cnt_feed[i]);
tmp |= (EXYNOS5_USE_SC_FEEDBACK |
EXYNOS5_USE_SC_COUNTER);
@@ -361,7 +375,7 @@ static void exynos5_init_pmu(void)
/*
 * Disable WFI/WFE on XXX_OPTION
 */
-   for (i = 0 ; i  ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
+   for (i = 0; i  ARRAY_SIZE(exynos5_list_diable_wfi_wfe); i++) {
tmp = pmu_raw_readl(exynos5_list_diable_wfi_wfe[i]);
tmp = ~(EXYNOS5_OPTION_USE_STANDBYWFE |
 EXYNOS5_OPTION_USE_STANDBYWFI);
@@ -373,51 +387,124 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
 {
unsigned int i;
 
-   if (soc_is_exynos5250())
-   exynos5_init_pmu();
+   const struct exynos_pmu_data *pmu_data = pmu_context-pmu_data;
 
-   for (i = 0; (exynos_pmu_config[i].offset != PMU_TABLE_END) ; i++)
-   pmu_raw_writel(exynos_pmu_config[i].val[mode],
-   exynos_pmu_config[i].offset);
+   if (pmu_data-powerdown_conf)
+   pmu_data-powerdown_conf(mode);
 
-   if (soc_is_exynos4412()) {
-   for (i = 0; exynos4412_pmu_config[i].offset != PMU_TABLE_END ; 
i++)
-   pmu_raw_writel(exynos4412_pmu_config[i].val[mode],
-   exynos4412_pmu_config[i].offset);
+   if (pmu_data-pmu_config) {
+   for (i = 0; (pmu_data-pmu_config[i].offset != PMU_TABLE_END); 
i++)
+   pmu_raw_writel(pmu_data-pmu_config[i].val[mode],
+   pmu_data-pmu_config[i].offset);
+   }
+
+   if (pmu_data-pmu_config_extra) {
+   for (i = 0; pmu_data-pmu_config_extra[i].offset != 
PMU_TABLE_END; i++)
+   pmu_raw_writel(pmu_data-pmu_config_extra[i].val[mode],
+   pmu_data-pmu_config_extra[i].offset);
}
 }
 
-static int __init exynos_pmu_init(void)
+static void exynos5250_pmu_init(void)
 {
unsigned int value;
+   /*
+* When 

[PATCH v9 0/2] ARM: Exynos: Convert PMU implementation into a platform driver

[Pankaj Dubey]

This patch series, modifies Exynos Power Management Unit (PMU) related code
for converting it into a platform_driver. This is also preparation for moving
PMU related code out of machine folder into a either drivers/mfd, or
drivers/power or some other suitable place so that ARM64 based SoC can
utilize common piece of code.

These patches are created on top of Kukjin Kim's for-next.

Vikas Sajjan have tested these patches on Exynos5420 based Peach board for
system boot and S2R.

This patch series depends on following patch series:
[1]: mfd: syscon: Decouple syscon interface from syscon devices.
 https://lkml.org/lkml/2014/9/30/156

Patch v8 and discussion can be found here:
http://www.spinics.net/lists/arm-kernel/msg366831.html

Change since v8:
 - Changed __raw_readl/writel into readl/writel_relaxed as suggested by Arnd.

Change since v7:
 - Removing registration of syscon provider. As it will be handled now by
   syscon patch [1].
 - Rebased on top of latest kgene/for-next.
 
Change since v6:
 - Removed NULL check for pmu_data in pmu.c.
 - Moved pmu_raw_readl and pmu_raw_writel inline helper function
   into common.h.
  
Change Since v5:
 - Squashed patch Move mach/map.h inclusion from regs-pmu.h to platsmp.c
   into patch Refactored code for using PMU address via DT.
 - Addressed review comments from Tomasz Figa.
 - Using init_irq machine function to initialize PMU mapping instead
   of init_time.
 - Rebased on latest Kukjin Kim's for-next branch.

Changes Since v4:
 - Splitted patch series in two parts. Part 1 has code cleanup under mach-exynos
   and posted as separate patch [2]. Current patchset is part 2 which modified
   exynos pmu implementation for making it platform driver.
 - Removed dependency over early_syscon API.
 - Removed usage of regmap read/write APIs.
 - Modified probe function to register exynos pmu as syscon provider using
   Tomasz Figa's syscon patch [1].
 - Address various other review comments from Tomasz Figa.
 - Removed signed-off-by of Young-Gun Jang yg1004.jang at samsung.com,
   as this id is no more valid. Taking ownership of all his patches.

Changes Since v3:
 - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init
   as suggested by Vikas Sajjan.
 - Modified syscon_early_regmap_lookup_by_phandle and
   syscon_regmap_lookup_by_phandle function call to pass property as NULL.

Changes Since v2:
 - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches.
 - Removed early mapping of PMU base address from exynos.c and removed
   get_exynos_pmuaddr function. Instead of this added code in platsmp.c
   to get PMU base address using of_iomap as suggested by Tomasz Figa.
 - Converted PMU implementation into platform_driver by using static
   platform_device method. 

Changes Since v1:
 - Rebased on latest for-next of Kukjin Kim's tree.
 - Updated patch: Add support for mapping PMU base address via DT
- Removed __initdata from declaration of exynos_pmu_base, as it caused
kernel crash as pointed out by Vikas Sajjan.
- Added support for Syscon initialization and getting PMU regmap handle
as suggested by Sylwester. Since current implementation of early
intialization [1] has limitation that early_syscon_init requires
DT to be unflattened and system should be able to allocate memory,
we can't use regmap handles for platsmp.c file as smp_secondary_init
will be called before DT unflattening. So I have kept both method for
accessing PMU base address. platsmp.c will use ioremmaped address where
as rest other files can use regmap handle.
 - Updated patch: Refactored code for PMU register mapping via DT
- Modified to use regmap_read/write when using regmap handle.
 - Added patch: Add device tree based initialization support for PMU.
- Convert existing PMU implementation to be a device tree based 
 before moving it to drivers/mfd folder. As suggested by Bartlomiej.
- Dropped making a platform_driver for PMU, as currently PMU binding
has two compatibility strings as samsung, exynosxxx-pmu, syscon,
once we enable MFD_SYSCON config option, current syscon driver probe
gets called and PMU probe never gets called. So modified PMU
initialization code to scan DT and match against supported compatiblity
string in driver code, and once we get matching node use that for
accessing PMU regmap handle using 
syscon_early_regmap_lookup_by_phandle.
If there is any better solution please suggest.


Pankaj Dubey (2):
  ARM: EXYNOS: Add platform driver support for Exynos PMU
  ARM: EXYNOS: Move PMU specific definitions from common.h

 arch/arm/mach-exynos/Kconfig  |1 +
 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|  191 -
 

[PATCH v9 2/2] ARM: EXYNOS: Move PMU specific definitions from common.h

[Pankaj Dubey]

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

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index d4d09bc..431be1b 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -139,23 +139,6 @@ extern void exynos_cpu_resume_ns(void);
 
 extern struct smp_operations exynos_smp_ops;
 
-/* PMU(Power Management Unit) support */
-
-#define PMU_TABLE_END  (-1U)
-
-enum sys_powerdown {
-   SYS_AFTR,
-   SYS_LPA,
-   SYS_SLEEP,
-   NUM_SYS_POWERDOWN,
-};
-
-struct exynos_pmu_conf {
-   unsigned int offset;
-   unsigned int val[NUM_SYS_POWERDOWN];
-};
-
-extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
 extern void exynos_cpu_power_down(int cpu);
 extern void exynos_cpu_power_up(int cpu);
 extern int  exynos_cpu_power_state(int cpu);
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..a2ab0d5
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+enum sys_powerdown {
+   SYS_AFTR,
+   SYS_LPA,
+   SYS_SLEEP,
+   NUM_SYS_POWERDOWN,
+};
+
+extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 4f10fa6..86f3ecd 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -26,6 +26,7 @@
 #include plat/pm-common.h
 
 #include common.h
+#include exynos-pmu.h
 #include regs-pmu.h
 #include regs-sys.h
 
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 1f5aaa7..1993e08 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -13,9 +13,16 @@
 #include linux/of.h
 #include linux/platform_device.h
 
-#include common.h
+#include exynos-pmu.h
 #include regs-pmu.h
 
+#define PMU_TABLE_END  (-1U)
+
+struct exynos_pmu_conf {
+   unsigned int offset;
+   unsigned int val[NUM_SYS_POWERDOWN];
+};
+
 struct exynos_pmu_data {
const struct exynos_pmu_conf *pmu_config;
const struct exynos_pmu_conf *pmu_config_extra;
@@ -29,8 +36,19 @@ struct exynos_pmu_context {
const struct exynos_pmu_data *pmu_data;
 };
 
+static void __iomem *pmu_base_addr;
 static struct exynos_pmu_context *pmu_context;
 
+static inline void pmu_raw_writel(u32 val, u32 offset)
+{
+   writel_relaxed(val, pmu_base_addr + offset);
+}
+
+static inline u32 pmu_raw_readl(u32 offset)
+{
+   return readl_relaxed(pmu_base_addr + offset);
+}
+
 static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
{ S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index f5d9773..079d999 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -33,6 +33,7 @@
 #include common.h
 #include regs-pmu.h
 #include regs-sys.h
+#include exynos-pmu.h
 
 #define S5P_CHECK_SLEEP 0x0BAD
 
-- 
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

[Tomi Valkeinen]

On 25/09/14 09:23, Thierry Reding wrote:

 How are cameras different? The CPU wants to capture video data from the
 camera, so it needs to go look for a video capture device, which in turn
 needs to involve a sensor.

Let's say we have an XXX-to-YYY encoder. We use that encoder to convert
the SoC's XXX output to YYY, which is then shown on a panel. So, in this
case, the encoder's DT node will have a panel or output phandle,
pointing to the panel.

We then use the exact same encoder in a setup in which we have a camera
which outputs XXX, which the encoder then converts to YYY, which is then
captured by the SoC. Here the output phandle would point to the SoC.

 If you go the other way around, how do you detect how things connect?
 Where do you get the information about the panel so you can trace back
 to the origin?

 When the panel driver probes, it registers itself as a panel and gets
 its video source. Similarly a bridge in between gets its video source,
 which often would be the SoC, i.e. the origin.
 
 That sounds backwards to me. The device tree serves the purpose of
 supplementing missing information that can't be probed if hardware is
 too stupid. I guess that's one of the primary reasons for structuring it
 the way we do, from the CPU point of view, because it allows the CPU to
 probe via the device tree.
 
 Probing is always done downstream, so you'd start by looking at some
 type of bus interface and query it for what devices are present on the
 bus. Take for example PCI: the CPU only needs to know how to access the
 host bridge and will then probe devices behind each of the ports on that
 bridge. Some of those devices will be bridges, too, so it will continue
 to probe down the hierarchy.
 
 Without DT you don't have a means to know that there was a panel before
 you've actually gone and probed your whole hierarchy and found a GPU
 with some sort of output that a panel can be connected to. I think it
 makes a lot of sense to describe things in the same way in DT.

Maybe I don't quite follow, but it sounds to be you are mixing control
and data. For control, all you say is true. The CPU probes the devices
on control busses, either with the aid of HW or the aid of DT, going
downstream.

But the data paths are a different matter. The CPU/SoC may not even be
involved in the whole data path. You could have a sensor on the board
directly connected to a panel. Both are controlled by the CPU, but the
data path goes from the sensor to the panel (or vice versa). There's no
way the data paths can be CPU centric in that case.

Also, a difference with the data paths compared to control paths is that
they are not strictly needed for operation. An encoder can generate an
output without enabling its input (test pattern or maybe blank screen,
or maybe a screen with company logo). Or an encoder with two inputs
might only get the second input when the user requests a very high res
mode. So it is possible that the data paths are lazily initialized.

You do know that there is a panel right after the device is probed
according to its control bus. It doesn't mean that the data paths are
there yet. In some cases the user space needs to reconfigure the data
paths before a panel has an input and can be used to show an image from
the SoC's display subsystem.

The point here being that the data path bindings don't really relate to
the probing part. You can probe no matter which way the data path
bindings go, and no matter if there actually exists (yet) a probed
device on the other end of a data path phandle.

While I think having video data connections in DT either way, downstream
or upstream, would work, it has felt most natural for me to have the
phandles from video sinks to video sources.

The reason for that is that I think the video sink has to be in control
of its source. It's the sink that tells the source to start or stop or
reconfigure. So I have had need to get the video source from a video
sink, but I have never had the need to get the video sinks from video
sources.

 Tomi




signature.asc
Description: OpenPGP digital signature

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

[Javier Martinez Canillas]

Hello Abhilash,

On Mon, Oct 6, 2014 at 11:08 AM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
 diff --git a/arch/arm/mach-exynos/platsmp.c 
 b/arch/arm/mach-exynos/platsmp.c
 index adb36a8..222aa3c 100644
 --- a/arch/arm/mach-exynos/platsmp.c
 +++ b/arch/arm/mach-exynos/platsmp.c
 @@ -137,6 +137,18 @@ void exynos_cpu_power_down(int cpu)
   */
  void exynos_cpu_power_up(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 = __raw_readl(pmu_base_addr +
 +   EXYNOS5_ARM_CORE0_SYS_PWR_REG);
 +   if (!(val  S5P_CORE_LOCAL_PWR_EN))
 +   return;
 +   }
 pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
 EXYNOS_ARM_CORE_CONFIGURATION(cpu));
  }

 The above block of code should be in exynos_cpu_power_down(). Can you
 re-test s2r after modifying it ? I have to convert a __raw_readl to
 pmu_raw_readl in this patch as well. Once Vikas re-works the base s2r
 patch I will re-post a v9.


 Thanks, for the information but unfortunately even after this change I
 still have the issue reported in [0]. I also removed the lines from
 exynos5420_pm_resume() that you asked Vikash [1].

 I have just tested this on the 5420 that I have and it resumes fine.
 The difference could be in the bootloader we are using. I'll send out
 details of my current setup so that you can cross-check if everything
 is the same.

Thanks a lot for sending me the patches you are using to test.

But after looking at the differences I noticed that your patches are
not removing the lines that set the CPU0 low power states at the start
of exynos5420_pm_resume() as you asked Vikas [1] but instead your
version of this patch does not have the code that does the same
operation after the early_wakeup label like is made in $subject.

IOW, this [2] is what I had to change on top of $subject to have s2r
working. After that change, both suspending to ram and resuming due
the RTC IRQ alarm being triggered and the core pm_test case works well
on my Exynos5420 Peach Pit.


 Regards,
 Abhilash

Best regards,
Javier

[0]: http://www.spinics.net/lists/arm-kernel/msg367615.html
[1]: http://www.spinics.net/lists/linux-samsung-soc/msg37561.html
[2]: http://pastebin.com/raw.php?i=XSxJH3Ys
--
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 v8] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420

[Abhilash Kesavan]

Hi Javier,

On Mon, Oct 6, 2014 at 5:29 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 Hello Abhilash,

 On Mon, Oct 6, 2014 at 11:08 AM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
 diff --git a/arch/arm/mach-exynos/platsmp.c 
 b/arch/arm/mach-exynos/platsmp.c
 index adb36a8..222aa3c 100644
 --- a/arch/arm/mach-exynos/platsmp.c
 +++ b/arch/arm/mach-exynos/platsmp.c
 @@ -137,6 +137,18 @@ void exynos_cpu_power_down(int cpu)
   */
  void exynos_cpu_power_up(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 = __raw_readl(pmu_base_addr +
 +   EXYNOS5_ARM_CORE0_SYS_PWR_REG);
 +   if (!(val  S5P_CORE_LOCAL_PWR_EN))
 +   return;
 +   }
 pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
 EXYNOS_ARM_CORE_CONFIGURATION(cpu));
  }

 The above block of code should be in exynos_cpu_power_down(). Can you
 re-test s2r after modifying it ? I have to convert a __raw_readl to
 pmu_raw_readl in this patch as well. Once Vikas re-works the base s2r
 patch I will re-post a v9.


 Thanks, for the information but unfortunately even after this change I
 still have the issue reported in [0]. I also removed the lines from
 exynos5420_pm_resume() that you asked Vikash [1].

 I have just tested this on the 5420 that I have and it resumes fine.
 The difference could be in the bootloader we are using. I'll send out
 details of my current setup so that you can cross-check if everything
 is the same.

 Thanks a lot for sending me the patches you are using to test.

 But after looking at the differences I noticed that your patches are
 not removing the lines that set the CPU0 low power states at the start
 of exynos5420_pm_resume() as you asked Vikas [1] but instead your
 version of this patch does not have the code that does the same
 operation after the early_wakeup label like is made in $subject.

The reason for my asking Vikas to remove the lines that restore the
core low power state register from the base s2r patch was because it
should be part of the mcpm s2r patch where the actual setting of the
register takes place.
Regarding the location of those lines we should be restoring the
register as early as possible, so my next version would have it at the
beginning of exynos5420_pm_resume.

 IOW, this [2] is what I had to change on top of $subject to have s2r
 working. After that change, both suspending to ram and resuming due
 the RTC IRQ alarm being triggered and the core pm_test case works well
 on my Exynos5420 Peach Pit.

That's good. Thanks for testing !

Regards,
Abhilash


 Regards,
 Abhilash

 Best regards,
 Javier

 [0]: http://www.spinics.net/lists/arm-kernel/msg367615.html
 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg37561.html
 [2]: http://pastebin.com/raw.php?i=XSxJH3Ys
--
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/4] [media] exynos4-is: Remove optional dependency on PLAT_S5P

[Sergei Shtylyov]

Hello.

On 10/6/2014 1:08 PM, Paul Bolle wrote:


Commit d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code)
removed the Kconfig symbol PLAT_S5P. Remove an optional dependency on
that symbol from this Kconfig file too.



Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
  drivers/media/platform/exynos4-is/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 77c951237744..775c3278d0eb 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,7 +2,7 @@
  config VIDEO_SAMSUNG_EXYNOS4_IS
bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
-   depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+   depends on (ARCH_EXYNOS || COMPILE_TEST)


   Perhaps it's time to drop the useless parens?

WBR, Sergei

--
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/4] [media] exynos4-is: Remove optional dependency on PLAT_S5P

[Sylwester Nawrocki]

On 06/10/14 14:37, Sergei Shtylyov wrote:
 diff --git a/drivers/media/platform/exynos4-is/Kconfig 
 b/drivers/media/platform/exynos4-is/Kconfig
 index 77c951237744..775c3278d0eb 100644
 --- a/drivers/media/platform/exynos4-is/Kconfig
 +++ b/drivers/media/platform/exynos4-is/Kconfig
 @@ -2,7 +2,7 @@
   config VIDEO_SAMSUNG_EXYNOS4_IS
  bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
  depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
 -depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
 +depends on (ARCH_EXYNOS || COMPILE_TEST)
 
 Perhaps it's time to drop the useless parens?

Good point, let me prepare patches to clean that up.

--
Thanks,
Sylwester


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

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

[Laurent Pinchart]

Hi Tomi and Thierry,

On Monday 06 October 2014 14:34:00 Tomi Valkeinen wrote:
 On 25/09/14 09:23, Thierry Reding wrote:
  How are cameras different? The CPU wants to capture video data from the
  camera, so it needs to go look for a video capture device, which in turn
  needs to involve a sensor.
 
 Let's say we have an XXX-to-YYY encoder. We use that encoder to convert
 the SoC's XXX output to YYY, which is then shown on a panel. So, in this
 case, the encoder's DT node will have a panel or output phandle,
 pointing to the panel.
 
 We then use the exact same encoder in a setup in which we have a camera
 which outputs XXX, which the encoder then converts to YYY, which is then
 captured by the SoC. Here the output phandle would point to the SoC.

phandles are pretty simple and versatile, which is one of the reasons why they 
are widely used. The drawback is that they are used to model totally different 
concepts, which then get mixed in our brains.

The DT nodes that make a complete system are related in many different ways. 
DT has picked one of those relationships, namely the control parent-child 
relationship, made it special, and arranged the nodes in a tree structure 
based on those relationships. As Thierry mentioned this make sense given that 
DT addresses the lack of discoverability from a CPU point of view.

As many other relationships between nodes had to be represented in DT phandles 
got introduced. One of their use cases is to reference resources required by 
devices, such as GPIOs, clocks and regulators. In those cases the distinction 
between the resource provider and the resource user is clear. The provider and 
user roles are clearly identified in the relationship, with the user being the 
master and the provider being the slave.

After those first two classes of relationships (control parent/child and 
resource provider/user), a need to specify data connections in DT arose. 
Different models got adopted depending on the subsystems and/or devices, all 
based on phandles.

I believe this use case is different compared to the first two in that it 
defines connections, not master/slave relationships. The connection doesn't 
model which entity control or use the other (if any), but how data flows 
between entities. There is no clear master or slave in that model, different 
control models can then be implemented in device drivers depending on the use 
cases, but those are very much implementation details from a DT point of view. 
The composite device model used for display drivers (and camera drivers for 
that matter) usually sets all devices on equal footing, and then picks a 
master (which can be one of the hardware devices, or a virtual logical device) 
depending on the requirements of the kernel and/or userspace subsystem(s).

I thus don't think there's any point in arguing which entity is the resource 
and which entity is the user in this discussion, as that should be unrelated 
to the DT bindings. If we need to select a single phandle direction from a 
hardware description point of view, the only direction that makes sense is one 
based on the data flow direction. Making phandles always point outwards or 
inwards from the CPU point of view doesn't make sense, especially when the CPU 
doesn't get involved as a data point in a media pipeline (think about a 
connector - processing - connector pipeline for instance, where data will be 
processed by hardware only without going through system memory at any point).

Now, we also have to keep in mind that the DT description, while it should 
model the hardware, also needs to be usable from a software point of view. A 
hardware model that would precisely describe the system in very convoluted 
ways wouldn't be very useful. We thus need to select a model that will ease 
software development, while only describing the hardware and without depending 
on a particular software implementation. That model should be as simple as 
possible, but doesn't necessarily need to be the simplest model possible if 
that would result in many implementation issues.

I think the OF graph model is a good candidate here. It is unarguably more 
complex than a single phandle, but it also makes different software 
implementations possible while still keeping the DT completely low.

  If you go the other way around, how do you detect how things connect?
  Where do you get the information about the panel so you can trace back
  to the origin?
  
  When the panel driver probes, it registers itself as a panel and gets
  its video source. Similarly a bridge in between gets its video source,
  which often would be the SoC, i.e. the origin.
  
  That sounds backwards to me. The device tree serves the purpose of
  supplementing missing information that can't be probed if hardware is
  too stupid. I guess that's one of the primary reasons for structuring it
  the way we do, from the CPU point of view, because it allows the CPU to
  probe via the device tree.
  
  Probing is 

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

[Laurent Pinchart]

Hi Thierry,

On Tuesday 23 September 2014 16:49:38 Thierry Reding wrote:
 On Tue, Sep 23, 2014 at 02:52:24PM +0300, Laurent Pinchart wrote:
  On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
  On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
 [...]
 
  This becomes an issue even on Linux when considering video-related
  devices that can be part of either a capture pipeline or a display
  pipeline. If the link always goes in the data flow direction, then it
  will be easy to locate the downstream device (bridge or panel) from
  the display controller driver, but it would be much more difficult to
  locate the same device from a camera driver as all of a sudden the
  device would become an upstream device.
  
  Why?
  
  If you have graph:
  sensor -- camera
  
  Then camera register itself in some framework as a destination device
  and sensor looks in this framework for the device identified by remote
  endpoint. Then sensor tells camera it is connected to it and voila.
  
  Except that both kernelspace and userspace deal with cameras the other way
  around, the master device is the camera receiver, not the camera sensor.
  DRM is architected the same way, with the component that performs DMA
  operations being the master device.
 
 I don't see what's wrong with having the camera reference the sensor by
 phandle instead. That's much more natural in my opinion.

The problem, as explained by Tomi in a more recent e-mail (let's thus discuss 
the issue there) is that making the phandles pointing outwards from the CPU 
point of view stops working when the same chip or IP core can be used in both 
a camera and a display pipeline (and we have real use cases for that), or when 
the CPU isn't involved at all in the pipeline.

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

[Laurent Pinchart]

Hi Tomi,

On Wednesday 24 September 2014 11:42:06 Tomi Valkeinen wrote:
 On 23/09/14 17:45, Thierry Reding wrote:
  On Tue, Sep 23, 2014 at 02:31:35PM +0300, Tomi Valkeinen wrote:
  On 23/09/14 12:39, Thierry Reding wrote:
  My point is that if you use plain phandles you usually have the
  meta-data already. Referring to the above example, bridge0 knows that it
  should look for a bridge with phandle bridge1, whereas bridge1 knows
  that the device it is connected to is a panel.
  
  The bridge should not care what kind of device is there on the other
  end. The bridge just has an output, going to another video component.
  
  You'll need to know at some point that one of the devices in a panel,
  otherwise you can't treat it like a panel.
 
 The bridge doesn't need to treat it like a panel. Someone else might,
 though. But the panel driver knows it is a panel, and can thus register
 needed services, or mark itself as a panel.
 
  Well, I can't say about this particular bridge, but afaik you can
  connect a parallel RGB signal to multiple panels just like that,
  without any muxing.
  
  Right, but in that case you're not reconfiguring the signal in any way
  for each of the panels. You send one single signal to all of them. For
  
  Yes, that's one use case, cloning. But I was not talking about that.
  
  all intents and purposes there is only one panel. Well, I guess you
  could have separate backlights for the panels. In that case though it
  seems better to represent it at least as a virtual mux or bridge, or
  perhaps a mux panel.
  
  I was talking about the case where you have two totally different
  devices, let's say panels, connected to the same output. One could take
  a 16-bit parallel RGB signal, the other 24-bit. Only one of them can  be
  enabled at a time (from HW perspective both can be enabled at the same
  time, but then the other one shows garbage).
  
  So we're essentially back to a mux, albeit maybe a virtual one.
 
 Yes. Are you suggesting to model virtual hardware in .dts? I got the
 impression that you wanted to model only the real hardware in .dts =).
 
 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.

-- 
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] [media] Remove references to non-existent PLAT_S5P symbol

[Sylwester Nawrocki]

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
---
 drivers/media/platform/Kconfig|6 +++---
 drivers/media/platform/exynos4-is/Kconfig |4 ++--
 drivers/media/platform/s5p-tv/Kconfig |2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index bee9074..3aac88f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -166,7 +166,7 @@ config VIDEO_MEM2MEM_DEINTERLACE
 config VIDEO_SAMSUNG_S5P_G2D
tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver
depends on VIDEO_DEV  VIDEO_V4L2
-   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
@@ -178,7 +178,7 @@ config VIDEO_SAMSUNG_S5P_G2D
 config VIDEO_SAMSUNG_S5P_JPEG
tristate Samsung S5P/Exynos3250/Exynos4 JPEG codec driver
depends on VIDEO_DEV  VIDEO_V4L2
-   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
@@ -189,7 +189,7 @@ config VIDEO_SAMSUNG_S5P_JPEG
 config VIDEO_SAMSUNG_S5P_MFC
tristate Samsung S5P MFC Video Codec
depends on VIDEO_DEV  VIDEO_V4L2
-   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 77c9512..b3b270a 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,7 +2,7 @@
 config VIDEO_SAMSUNG_EXYNOS4_IS
bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
-   depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on OF  COMMON_CLK
help
  Say Y here to enable camera host interface devices for
@@ -57,7 +57,7 @@ endif
 
 config VIDEO_EXYNOS4_FIMC_IS
tristate EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
-   depends on HAS_DMA
+   depends on HAS_DMA  !ARCH_S5PV210
select VIDEOBUF2_DMA_CONTIG
depends on OF
select FW_LOADER
diff --git a/drivers/media/platform/s5p-tv/Kconfig 
b/drivers/media/platform/s5p-tv/Kconfig
index a9d56f8..beb180e 100644
--- a/drivers/media/platform/s5p-tv/Kconfig
+++ b/drivers/media/platform/s5p-tv/Kconfig
@@ -9,7 +9,7 @@
 config VIDEO_SAMSUNG_S5P_TV
bool Samsung TV driver for S5P platform
depends on PM_RUNTIME
-   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
default n
---help---
  Say Y here to enable selecting the TV output devices for
-- 
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] usb: Remove references to non-existent PLAT_S5P symbol

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

Reported-by: Paul Bolle pebo...@tiscali.nl
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 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

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

[Tomasz Figa]

On 06.10.2014 17:39, Sylwester Nawrocki wrote:
 diff --git a/drivers/media/platform/exynos4-is/Kconfig 
 b/drivers/media/platform/exynos4-is/Kconfig
 index 77c9512..b3b270a 100644
 --- a/drivers/media/platform/exynos4-is/Kconfig
 +++ b/drivers/media/platform/exynos4-is/Kconfig
 @@ -2,7 +2,7 @@
  config VIDEO_SAMSUNG_EXYNOS4_IS
   bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
   depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
 - depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
 + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
   depends on OF  COMMON_CLK
   help
 Say Y here to enable camera host interface devices for
 @@ -57,7 +57,7 @@ endif
  
  config VIDEO_EXYNOS4_FIMC_IS
   tristate EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
 - depends on HAS_DMA
 + depends on HAS_DMA  !ARCH_S5PV210

Hmm, does this change really do the intended thing?

Since both S5PV210 and Exynos are multiplatform-aware, now whenever
ARCH_S5PV210 is enabled, it isn't possible to enable
VIDEO_EXYNOS4_FIMC_IS, even though ARCH_EXYNOS can be enabled as well at
the same time.

Best regards,
Tomasz
--
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] [media] Remove references to non-existent PLAT_S5P symbol

[Sylwester Nawrocki]

On 06/10/14 17:52, Tomasz Figa wrote:
 On 06.10.2014 17:39, Sylwester Nawrocki wrote:
 diff --git a/drivers/media/platform/exynos4-is/Kconfig 
 b/drivers/media/platform/exynos4-is/Kconfig
 index 77c9512..b3b270a 100644
 --- a/drivers/media/platform/exynos4-is/Kconfig
 +++ b/drivers/media/platform/exynos4-is/Kconfig
 @@ -2,7 +2,7 @@
  config VIDEO_SAMSUNG_EXYNOS4_IS
  bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
  depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
 -depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
 +depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
  depends on OF  COMMON_CLK
  help
Say Y here to enable camera host interface devices for
 @@ -57,7 +57,7 @@ endif
  
  config VIDEO_EXYNOS4_FIMC_IS
  tristate EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
 -depends on HAS_DMA
 +depends on HAS_DMA  !ARCH_S5PV210
 
 Hmm, does this change really do the intended thing?
 
 Since both S5PV210 and Exynos are multiplatform-aware, now whenever
 ARCH_S5PV210 is enabled, it isn't possible to enable
 VIDEO_EXYNOS4_FIMC_IS, even though ARCH_EXYNOS can be enabled as well at
 the same time.

Sorry, I missed S5PV210 supports ARCH_MULTIPLATFORM, let me resend
with that line removed. Thanks for pointing out.

--
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 v2] [media] Remove references to non-existent PLAT_S5P symbol

[Sylwester Nawrocki]

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
---
 drivers/media/platform/Kconfig|6 +++---
 drivers/media/platform/exynos4-is/Kconfig |2 +-
 drivers/media/platform/s5p-tv/Kconfig |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index bee9074..3aac88f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -166,7 +166,7 @@ config VIDEO_MEM2MEM_DEINTERLACE
 config VIDEO_SAMSUNG_S5P_G2D
tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver
depends on VIDEO_DEV  VIDEO_V4L2
-   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
@@ -178,7 +178,7 @@ config VIDEO_SAMSUNG_S5P_G2D
 config VIDEO_SAMSUNG_S5P_JPEG
tristate Samsung S5P/Exynos3250/Exynos4 JPEG codec driver
depends on VIDEO_DEV  VIDEO_V4L2
-   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
@@ -189,7 +189,7 @@ config VIDEO_SAMSUNG_S5P_JPEG
 config VIDEO_SAMSUNG_S5P_MFC
tristate Samsung S5P MFC Video Codec
depends on VIDEO_DEV  VIDEO_V4L2
-   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 77c9512..b7b2e47 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,7 +2,7 @@
 config VIDEO_SAMSUNG_EXYNOS4_IS
bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
-   depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on OF  COMMON_CLK
help
  Say Y here to enable camera host interface devices for
diff --git a/drivers/media/platform/s5p-tv/Kconfig 
b/drivers/media/platform/s5p-tv/Kconfig
index a9d56f8..beb180e 100644
--- a/drivers/media/platform/s5p-tv/Kconfig
+++ b/drivers/media/platform/s5p-tv/Kconfig
@@ -9,7 +9,7 @@
 config VIDEO_SAMSUNG_S5P_TV
bool Samsung TV driver for S5P platform
depends on PM_RUNTIME
-   depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
+   depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
default n
---help---
  Say Y here to enable selecting the TV output devices for
--
1.7.9.5

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

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

[Paul Bolle]

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?

  drivers/media/platform/Kconfig|6 +++---
  drivers/media/platform/exynos4-is/Kconfig |2 +-
  drivers/media/platform/s5p-tv/Kconfig |2 +-
  3 files changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
 index bee9074..3aac88f 100644
 --- a/drivers/media/platform/Kconfig
 +++ b/drivers/media/platform/Kconfig
 @@ -166,7 +166,7 @@ config VIDEO_MEM2MEM_DEINTERLACE
  config VIDEO_SAMSUNG_S5P_G2D
   tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver
   depends on VIDEO_DEV  VIDEO_V4L2
 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
 + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
   depends on HAS_DMA
   select VIDEOBUF2_DMA_CONTIG
   select V4L2_MEM2MEM_DEV
 @@ -178,7 +178,7 @@ config VIDEO_SAMSUNG_S5P_G2D
  config VIDEO_SAMSUNG_S5P_JPEG
   tristate Samsung S5P/Exynos3250/Exynos4 JPEG codec driver
   depends on VIDEO_DEV  VIDEO_V4L2
 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
 + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
   depends on HAS_DMA
   select VIDEOBUF2_DMA_CONTIG
   select V4L2_MEM2MEM_DEV
 @@ -189,7 +189,7 @@ config VIDEO_SAMSUNG_S5P_JPEG
  config VIDEO_SAMSUNG_S5P_MFC
   tristate Samsung S5P MFC Video Codec
   depends on VIDEO_DEV  VIDEO_V4L2
 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
 + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
   depends on HAS_DMA
   select VIDEOBUF2_DMA_CONTIG
   default n
 diff --git a/drivers/media/platform/exynos4-is/Kconfig 
 b/drivers/media/platform/exynos4-is/Kconfig
 index 77c9512..b7b2e47 100644
 --- a/drivers/media/platform/exynos4-is/Kconfig
 +++ b/drivers/media/platform/exynos4-is/Kconfig
 @@ -2,7 +2,7 @@
  config VIDEO_SAMSUNG_EXYNOS4_IS
   bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
   depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
 - depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
 + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
   depends on OF  COMMON_CLK
   help
 Say Y here to enable camera host interface devices for
 diff --git a/drivers/media/platform/s5p-tv/Kconfig 
 b/drivers/media/platform/s5p-tv/Kconfig
 index a9d56f8..beb180e 100644
 --- a/drivers/media/platform/s5p-tv/Kconfig
 +++ b/drivers/media/platform/s5p-tv/Kconfig
 @@ -9,7 +9,7 @@
  config VIDEO_SAMSUNG_S5P_TV
   bool Samsung TV driver for S5P platform
   depends on PM_RUNTIME
 - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
 + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
   default n
   ---help---
 Say Y here to enable selecting the TV output devices for


Paul Bolle

--
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] usb: Remove references to non-existent PLAT_S5P symbol

[Paul Bolle]

On Mon, 2014-10-06 at 17:47 +0200, Sylwester Nawrocki wrote:
 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.
 
 Reported-by: Paul Bolle pebo...@tiscali.nl
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com

As with the [media] patch: should
 Fixes: d78c16ccde96 (ARM: SAMSUNG: Remove remaining legacy code)

be added so this will end up in stable for v3.17?

  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.
  

Thanks again!


Paul Bolle

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

Re: [PATCH] ARM: dts: Specify Odroid X2/U3 audio clock parents and rates

[Sylwester Nawrocki]

On 10/09/14 16:43, Sylwester Nawrocki wrote:
 This ensures the core and the audio subsystem clocks are configured
 properly, as expected by the sound machine driver. These bits are
 missing to obtain proper audio sample rates in kernel v3.17, where
 audio support for Odroid X2/U3 was first added.
 
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
 It would be good to have it applied as a fix for v3.17.

Anything happened to this patch ? I can't see it neither in Linus' nor
-next tree. And we are already at 3.18 merge window.

  arch/arm/boot/dts/exynos4412-odroid-common.dtsi |   10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
 b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 index adadaf9..b40f766 100644
 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 @@ -45,6 +45,16 @@
   compatible = samsung,odroidx2-audio;
   samsung,i2s-controller = i2s0;
   samsung,audio-codec = max98090;
 + assigned-clocks = clock_audss EXYNOS_MOUT_AUDSS,
 + clock_audss EXYNOS_MOUT_I2S,
 + clock_audss EXYNOS_DOUT_SRP,
 + clock_audss EXYNOS_DOUT_AUD_BUS;
 + assigned-clock-parents = clock CLK_FOUT_EPLL,
 + clock_audss EXYNOS_MOUT_AUDSS;
 + assigned-clock-rates = 0,
 + 0,
 + 19200,
 + 1920;
   };
 
   mmc@1255 {
 --
 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] ARM: dts: fix MMC2 regulators for Exynos5420 Arndale Octa board

[Doug Anderson]

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?


-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] usb: Remove references to non-existent PLAT_S5P symbol

[Jingoo Han]

On Tuesday, October 07, 2014 12:47 AM, Sylwester Nawrocki wrote:
 
 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.
 
 Reported-by: Paul Bolle pebo...@tiscali.nl
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

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

RE: [PATCH v9 0/2] ARM: Exynos: Convert PMU implementation into a platform driver

[Kukjin Kim]

Pankaj Dubey wrote:
 
 This patch series, modifies Exynos Power Management Unit (PMU) related code
 for converting it into a platform_driver. This is also preparation for moving
 PMU related code out of machine folder into a either drivers/mfd, or
 drivers/power or some other suitable place so that ARM64 based SoC can
 utilize common piece of code.
 
 These patches are created on top of Kukjin Kim's for-next.
 
 Vikas Sajjan have tested these patches on Exynos5420 based Peach board for
 system boot and S2R.
 
 This patch series depends on following patch series:
 [1]: mfd: syscon: Decouple syscon interface from syscon devices.
  https://lkml.org/lkml/2014/9/30/156
 
 Patch v8 and discussion can be found here:
 http://www.spinics.net/lists/arm-kernel/msg366831.html
 
 Change since v8:
  - Changed __raw_readl/writel into readl/writel_relaxed as suggested by Arnd.
 
 Change since v7:
  - Removing registration of syscon provider. As it will be handled now by
syscon patch [1].
  - Rebased on top of latest kgene/for-next.
 
 Change since v6:
  - Removed NULL check for pmu_data in pmu.c.
  - Moved pmu_raw_readl and pmu_raw_writel inline helper function
into common.h.
 
 Change Since v5:
  - Squashed patch Move mach/map.h inclusion from regs-pmu.h to platsmp.c
into patch Refactored code for using PMU address via DT.
  - Addressed review comments from Tomasz Figa.
  - Using init_irq machine function to initialize PMU mapping instead
of init_time.
  - Rebased on latest Kukjin Kim's for-next branch.
 
 Changes Since v4:
  - Splitted patch series in two parts. Part 1 has code cleanup under 
 mach-exynos
and posted as separate patch [2]. Current patchset is part 2 which modified
exynos pmu implementation for making it platform driver.
  - Removed dependency over early_syscon API.
  - Removed usage of regmap read/write APIs.
  - Modified probe function to register exynos pmu as syscon provider using
Tomasz Figa's syscon patch [1].
  - Address various other review comments from Tomasz Figa.
  - Removed signed-off-by of Young-Gun Jang yg1004.jang at samsung.com,
as this id is no more valid. Taking ownership of all his patches.
 
 Changes Since v3:
  - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init
as suggested by Vikas Sajjan.
  - Modified syscon_early_regmap_lookup_by_phandle and
syscon_regmap_lookup_by_phandle function call to pass property as NULL.
 
 Changes Since v2:
  - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches.
  - Removed early mapping of PMU base address from exynos.c and removed
get_exynos_pmuaddr function. Instead of this added code in platsmp.c
to get PMU base address using of_iomap as suggested by Tomasz Figa.
  - Converted PMU implementation into platform_driver by using static
platform_device method.
 
 Changes Since v1:
  - Rebased on latest for-next of Kukjin Kim's tree.
  - Updated patch: Add support for mapping PMU base address via DT
   - Removed __initdata from declaration of exynos_pmu_base, as it caused
   kernel crash as pointed out by Vikas Sajjan.
   - Added support for Syscon initialization and getting PMU regmap handle
   as suggested by Sylwester. Since current implementation of early
   intialization [1] has limitation that early_syscon_init requires
   DT to be unflattened and system should be able to allocate memory,
   we can't use regmap handles for platsmp.c file as smp_secondary_init
   will be called before DT unflattening. So I have kept both method for
   accessing PMU base address. platsmp.c will use ioremmaped address where
   as rest other files can use regmap handle.
  - Updated patch: Refactored code for PMU register mapping via DT
   - Modified to use regmap_read/write when using regmap handle.
  - Added patch: Add device tree based initialization support for PMU.
   - Convert existing PMU implementation to be a device tree based
before moving it to drivers/mfd folder. As suggested by Bartlomiej.
   - Dropped making a platform_driver for PMU, as currently PMU binding
   has two compatibility strings as samsung, exynosxxx-pmu, syscon,
   once we enable MFD_SYSCON config option, current syscon driver probe
   gets called and PMU probe never gets called. So modified PMU
   initialization code to scan DT and match against supported compatiblity
   string in driver code, and once we get matching node use that for
   accessing PMU regmap handle using 
 syscon_early_regmap_lookup_by_phandle.
   If there is any better solution please suggest.
 
 
 Pankaj Dubey (2):
   ARM: EXYNOS: Add platform driver support for Exynos PMU
   ARM: EXYNOS: Move PMU specific definitions from common.h
 
  arch/arm/mach-exynos/Kconfig  |1 +
  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   

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

[Kukjin Kim]

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.

- Kukjin

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

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

[Pankaj Dubey]

Hi,

On Wednesday, October 01, 2014 7:23 PM Guenter Roeck wrote:
 On 10/01/2014 04:36 AM, Pankaj Dubey wrote:
  Let's register reboot_notifier 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|   25
 +
3 files changed, 25 insertions(+), 7 deletions(-)
 
  diff --git a/arch/arm/mach-exynos/common.h
  b/arch/arm/mach-exynos/common.h index 431be1b..865f878 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 aa394cb..3aa75b8e 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
  @@ -365,7 +360,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..c0855a5 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,15 @@ static void exynos5250_pmu_init(void)
  pmu_raw_writel(value, EXYNOS5_MASK_WDTRESET_REQUEST);
}
 
  +static int pmu_reboot_notify_handler(struct notifier_block *this,
  +   unsigned long code, void *unused)
  +{
  +   if (code == SYS_RESTART)
  +   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 +490,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_reboot_notifier = {
  +   .notifier_call = pmu_reboot_notify_handler,
  +   .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 +528,10
  @@ static int exynos_pmu_probe(struct platform_device *pdev)
 
  platform_set_drvdata(pdev, pmu_context);
 
  +   ret = register_reboot_notifier(pmu_reboot_notifier);
  +   if (ret)
  +   dev_err(dev, can't register reboot notifier err=%d\n,
ret);
  +
  dev_dbg(dev, Exynos PMU Driver probe done\n);
  return 0;
}
 
 
 Something went wrong here.
 
 You don't want to register with reboot_notifier, but with
restart_notifier.
 The code is not SYS_RESTART, but the value of reboot_mode.
 
 The same applies to the other patch as well.
 

Yes, you are right. Thanks for review and pointing out this.

Originally restart hooks of Exynos machine_desc are getting called from
machine_restart,
so I should have registered restart_notifier. Somehow I missed this part. I
will update both patches shortly.

Thanks,
Pankaj Dubey

 Guenter

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