[PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Mauro Carvalho Chehab]

Let's not mix headers used by the core with those headers that
are needed by some specific platform drivers.

This patch was made via this script:

mkdir include/media/platform
for i in include/media/*.h; do n=`basename $i`;  (for j in $(git grep 
-l $n); do dirname $j; done)|sort|uniq|grep -ve '^.$' > list; num=$(wc -l 
list|cut -d' ' -f1); if [ $num == 1 ]; then if [ "`grep platform list`" != "" 
]; then git mv $i include/media/platform; fi; fi; done
git mv include/media/exynos* include/media/s5p* include/media/omap* 
include/media/soc_* include/media/sh_include/media/platform/
for i in $(find include/media/ -type f); do n=`basename $i`; git grep 
-l $n; done|sort|uniq >files && (echo "for i in \$(cat files); do cat \$i | 
\\"; cd include/media; for j in rc/ i2c/ platform/ common_drv/; do for i in 
$(ls $j); do echo "perl -ne 's,(include 
[\\\"\\<]media/)($i)([\\\"\\>]),\1$j\2\3,; print \$_' |\\"; done; done; echo 
"cat > a && mv a \$i; done") >script && . ./script

Signed-off-by: Mauro Carvalho Chehab 

 rename include/media/{ => platform}/exynos-fimc.h (100%)
 rename include/media/{ => platform}/mmp-camera.h (100%)
 rename include/media/{ => platform}/omap1_camera.h (100%)
 rename include/media/{ => platform}/omap4iss.h (100%)
 rename include/media/{ => platform}/s3c_camif.h (100%)
 rename include/media/{ => platform}/s5p_hdmi.h (100%)
 rename include/media/{ => platform}/sh_mobile_ceu.h (100%)
 rename include/media/{ => platform}/sh_mobile_csi2.h (100%)
 rename include/media/{ => platform}/sh_vou.h (100%)
 rename include/media/{ => platform}/sii9234.h (100%)
 rename include/media/{ => platform}/soc_camera.h (100%)
 rename include/media/{ => platform}/soc_camera_platform.h (98%)
 rename include/media/{ => platform}/soc_mediabus.h (100%)

diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index ede2bdbb5dd5..99bd64c69a4f 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c 
b/arch/arm/mach-imx/mach-mx27_3ds.c
index 9ef4640f3660..74d073fd4fa6 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c 
b/arch/arm/mach-imx/mach-mx31_3ds.c
index 65a0dc06a97c..5e1b9c335103 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c 
b/arch/arm/mach-imx/mach-mx35_3ds.c
index 7e315f00648d..355b9521f7f0 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -45,7 +45,7 @@
 
 #include 
 
-#include 
+#include 
 
 #include "3ds_debugboard.h"
 #include "common.h"
diff --git a/arch/arm/mach-imx/mach-pcm037.c b/arch/arm/mach-imx/mach-pcm037.c
index 6d879417db49..02cc07b0a687 100644
--- a/arch/arm/mach-imx/mach-pcm037.c
+++ b/arch/arm/mach-imx/mach-pcm037.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mx31moboard-marxbot.c 
b/arch/arm/mach-imx/mx31moboard-marxbot.c
index 2e895a82a6eb..79ae360a9c8f 100644
--- a/arch/arm/mach-imx/mx31moboard-marxbot.c
+++ b/arch/arm/mach-imx/mx31moboard-marxbot.c
@@ -24,7 +24,7 @@
 
 #include 
 
-#include 
+#include 
 
 #include "common.h"
 #include "devices-imx31.h"
diff --git a/arch/arm/mach-imx/mx31moboard-smartbot.c 
b/arch/arm/mach-imx/mx31moboard-smartbot.c
index 89fc35a64448..00bd100df69a 100644
--- a/arch/arm/mach-imx/mx31moboard-smartbot.c
+++ b/arch/arm/mach-imx/mx31moboard-smartbot.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "board-mx31moboard.h"
 #include "common.h"
diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index a95499ea8706..7adef38f27c2 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/include/mach/camera.h 
b/arch/arm/mach-omap1/include/mach/camera.h
index 847d00f0bb0a..0df5ebf85de6 100644
--- a/arch/arm/mach-omap1/include/mach/camera.h
+++ b/arch/arm/mach-omap1/include/mach/camera.h
@@ -1,7 +1,7 @@
 #ifndef __ASM_ARCH_CAMERA_H_
 #define __ASM_ARCH_CAMERA_H_
 
-#include 
+#include 
 
 void omap1_camera_init(void *);
 
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index 9d7072b04045..ae645794ffd0 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff 

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Thomas Pietrowski]

When I was trying to build kernel 4.3.0 (from linux-stable) with
EXYNOS_IOMMU I was getting an kernel oop on boot, which forced me to
restart, so the kernel was not usable. Sadly I didn't make a paste of
it.
Can try to reproduce this error and send it if you like.

Are you not getting this error when building the kernel with it? (I
also own a Odroid U3+.)

Regards :)

2015-11-11 1:43 GMT+01:00 Krzysztof Kozlowski :
> On 10.11.2015 19:24, Marek Szyprowski wrote:
>> FIMD device is not used at all on Exynos5422-based Odroid XU3-lite and
>> XU4. XU3 board teorethically can support FIMD with DisplayPort
>
> s/teorethically/theoretically/
>
>> connector, but due to hw limitation/design it doesn't work in most
>> cases. It is also not even enabled in XU3 dts file.
>>
>> FIMD node was enabled mainly due to limitation of early Exynos DRM
>> driver, which didn't initialize properly when no FIMD device was
>> available. This node can be now safetly removed from XU3-common dtsi and
>
> s/safetly/safely/
>
>> added layer to Odroid XU3 dts, when Display Port driver gets enabled.
>>
>> Signed-off-by: Marek Szyprowski 
>> ---
>>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 5 -
>>  1 file changed, 5 deletions(-)
>
> Tested on Odroid XU4 board (HDMI, IOMMU enabled):
>
> Tested-by: Krzysztof Kozlowski 
> Reviewed-by: Krzysztof Kozlowski 
>
>
> No need for respin, the changelog fixes above can be done during applying.
>
>
> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
> Any reasons against?
>
> Best regards,
> Krzysztof
>
>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 1af5bdc..9134217 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -67,11 +67,6 @@
>>   <1920>;
>>  };
>>
>> - {
>> - status = "okay";
>> -};
>> -
>> -
>>   {
>>   status = "okay";
>>   hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
>>
>
> --
> 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

Re: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Krzysztof Kozlowski]

On 12.11.2015 05:43, Rob Herring wrote:
> On Wed, Nov 11, 2015 at 12:44 AM, Pavel Fedin  wrote:
>>  Hello!
>>
 +- samsung,srom-timing : array of 6 integers, specifying bank timings in 
 the
 +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, 
 Tacs.
 +Each value is specified in cycles and has the 
 following
 +meaning and valid range:
 +Tacp : Page mode access cycle at Page mode (0 - 
 15)
 +Tcah : Address holding time after CSn (0 - 15)
 +Tcoh : Chip selection hold on OEn (0 - 15)
 +Tacc : Access cycle (0 - 31, the actual time is N 
 + 1)
 +Tcos : Chip selection set-up before OEn (0 - 15)
 +Tacs : Address set-up before CSn (0 - 15)
>>>
>>> This is not easily extended. Perhaps a property per value instead.
>>
>>  We had a discussion with Krzysztof about it, he agreed with this form of 
>> the property.
>> My concern was that it's just too much typing, and makes little sense 
>> because these
>> settings always go together. If register layout changes, or parameter set 
>> changes in
>> incompatible way, then it's another device, not exynos-srom anymore.
>>  So would you agree with that, or is your position strong?
> 
> I'm thinking for a new version of the controller which could add (or
> remove) new timing parameters, but then I guess you can interpret the
> field differently based on the compatible string. Anyway, your problem
> to deal with.

Actually I also preferred properties per one timing... but finally
agreed on simpler approach.

Adding new parameters to the array is still possible (because the order
matters) and removal as well (by ignoring some indices). All ARMv7
Exynos SoCs have exactly the same registers for SROM controller
(Exynos3250, Exynos4, Exynos5). On newer Exynos ARMv8 (Exynos5433 and
Exynos7420) I don't know because it is not documented.

Best regards,
Krzysztof

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

Re: [PATCH v4 4/9] ARM: EXYNOS: split up exynos3250 SoC specific PMU data

[Krzysztof Kozlowski]

On 10.11.2015 20:42, Pankaj Dubey wrote:
> This patch splits up mach-exynos/pmu.c file, and moves exynos3250 PMU
> configuration data and functions handing those data into exynos3250
> SoC specific PMU file mach-exynos/exynos3250-pmu.c.
> 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/mach-exynos/Makefile |   2 +-
>  arch/arm/mach-exynos/exynos-pmu.h |  40 
>  arch/arm/mach-exynos/exynos.c |   2 -
>  arch/arm/mach-exynos/exynos3250-pmu.c | 175 
>  arch/arm/mach-exynos/pmu.c| 184 
> +-
>  5 files changed, 220 insertions(+), 183 deletions(-)
>  create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
>  create mode 100644 arch/arm/mach-exynos/exynos3250-pmu.c
> 
> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> index 2f30676..e869f86 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
> -I$(srctree)/$(src)/include -I$(srctree)
>  
>  # Core
>  
> -obj-$(CONFIG_ARCH_EXYNOS)+= exynos.o pmu.o exynos-smc.o firmware.o
> +obj-$(CONFIG_ARCH_EXYNOS)+= exynos.o pmu.o exynos-smc.o firmware.o 
> exynos3250-pmu.o
>  
>  obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
>  obj-$(CONFIG_PM_SLEEP)   += suspend.o
> diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
> b/arch/arm/mach-exynos/exynos-pmu.h
> new file mode 100644
> index 000..6f95c7d
> --- /dev/null
> +++ b/arch/arm/mach-exynos/exynos-pmu.h
> @@ -0,0 +1,40 @@
> +/*
> + * Copyright (c) 2015 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
> +
> +#include 
> +
> +#define PMU_TABLE_END(-1U)
> +
> +

Unnecessary blank line.

Rest looks good, so with this fix:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH v4 3/9] ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"

[Krzysztof Kozlowski]

On 10.11.2015 20:42, Pankaj Dubey wrote:
> Moving Exynos PMU specific header file into "include/linux/soc/samsung"
> thus updated affected files under "mach-exynos" to use new location of
> these header files.
> 
> Signed-off-by: Amit Daniel Kachhap 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/mach-exynos/exynos-pmu.h   |  24 -
>  arch/arm/mach-exynos/exynos.c   |   2 +-
>  arch/arm/mach-exynos/mcpm-exynos.c  |   2 +-
>  arch/arm/mach-exynos/platsmp.c  |   2 +-
>  arch/arm/mach-exynos/pm.c   |   4 +-
>  arch/arm/mach-exynos/pmu.c  |   6 +-
>  arch/arm/mach-exynos/regs-pmu.h | 693 
> 
>  arch/arm/mach-exynos/suspend.c  |   4 +-
>  include/linux/soc/samsung/exynos-pmu.h  |  24 +
>  include/linux/soc/samsung/exynos-regs-pmu.h | 693 
> 

Did you disable the rename-detection for format-patch? Default rename
detection mechanism (50% of similarity) should detect two renames here:
exynos-pmu.h and exynos-regs-pmu.h

Best regards,
Krzysztof


>  10 files changed, 727 insertions(+), 727 deletions(-)
>  delete mode 100644 arch/arm/mach-exynos/exynos-pmu.h
>  delete mode 100644 arch/arm/mach-exynos/regs-pmu.h
>  create mode 100644 include/linux/soc/samsung/exynos-pmu.h
>  create mode 100644 include/linux/soc/samsung/exynos-regs-pmu.h

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

Re: [PATCH v4 9/9] drivers: soc: Add support for Exynos PMU driver

[Krzysztof Kozlowski]

On 10.11.2015 20:43, Pankaj Dubey wrote:
> This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
> to "drivers/soc/samsung". This driver is mainly used for setting misc
> bits of register from PMU IP of Exynos SoC which will be required to
> configure before Suspend/Resume. Currently all these settings are done
> in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
> support, there is a need of this PMU driver in driver/* folder.
> 
> This driver uses existing DT binding information and there should
> be no functionality change in the supported platforms.
> 
> Signed-off-by: Amit Daniel Kachhap 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/mach-exynos/Kconfig  |   1 +
>  arch/arm/mach-exynos/Makefile |   4 +-
>  arch/arm/mach-exynos/exynos-pmu.h |  45 --
>  arch/arm/mach-exynos/exynos3250-pmu.c | 175 -
>  arch/arm/mach-exynos/exynos4-pmu.c| 223 ---
>  arch/arm/mach-exynos/exynos5250-pmu.c | 196 
>  arch/arm/mach-exynos/exynos5420-pmu.c | 280 
> --
>  arch/arm/mach-exynos/pmu.c| 183 --
>  drivers/soc/samsung/Kconfig   |   4 +
>  drivers/soc/samsung/Makefile  |   4 +
>  drivers/soc/samsung/exynos-pmu.c  | 183 ++
>  drivers/soc/samsung/exynos-pmu.h  |  45 ++
>  drivers/soc/samsung/exynos3250-pmu.c  | 175 +
>  drivers/soc/samsung/exynos4-pmu.c | 223 +++
>  drivers/soc/samsung/exynos5250-pmu.c  | 196 
>  drivers/soc/samsung/exynos5420-pmu.c  | 280 
> ++
>  16 files changed, 1112 insertions(+), 1105 deletions(-)
>  delete mode 100644 arch/arm/mach-exynos/exynos-pmu.h
>  delete mode 100644 arch/arm/mach-exynos/exynos3250-pmu.c
>  delete mode 100644 arch/arm/mach-exynos/exynos4-pmu.c
>  delete mode 100644 arch/arm/mach-exynos/exynos5250-pmu.c
>  delete mode 100644 arch/arm/mach-exynos/exynos5420-pmu.c
>  delete mode 100644 arch/arm/mach-exynos/pmu.c
>  create mode 100644 drivers/soc/samsung/exynos-pmu.c
>  create mode 100644 drivers/soc/samsung/exynos-pmu.h
>  create mode 100644 drivers/soc/samsung/exynos3250-pmu.c
>  create mode 100644 drivers/soc/samsung/exynos4-pmu.c
>  create mode 100644 drivers/soc/samsung/exynos5250-pmu.c
>  create mode 100644 drivers/soc/samsung/exynos5420-pmu.c

Again - renames were not detected. This is strange... and actually
unreadable. The previous patch looked much better. What happened?

Please send also entire patchset to linux-pm mailing list. I asked about
it last time and can't see it as recipient here.

Best regards,
Krzysztof

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

Re: [PATCH v4 2/9] ARM: EXYNOS: Fix potential NULL pointer access in exynos_sys_powerdown_conf

[Krzysztof Kozlowski]

On 10.11.2015 20:42, Pankaj Dubey wrote:
> If no platform devices binded to the driver but driver itself loaded and
> exynos_sys_powerdown_conf is called from
> arch/arm/mach-exynos/{suspend.c, pm.c} it will result in NULL pointer access,
> to prevent this added check on pmu_context for NULL.
> 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/mach-exynos/pmu.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH v4 8/9] ARM: EXYNOS: rearrange static and non-static functions of PMU driver

[Krzysztof Kozlowski]

On 10.11.2015 20:43, Pankaj Dubey wrote:
> This patch moves exynos_sys_powerdown_conf function above all
> static functions.

Please (always) describe the reason, the answer to "why?". In this case
I know why, but other reviewers may not and other people grepping
through history definitely won't know.

Best regards,
Krzysztof

> 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/mach-exynos/pmu.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
> index e01bdf1..f300ac9 100644
> --- a/arch/arm/mach-exynos/pmu.c
> +++ b/arch/arm/mach-exynos/pmu.c
> @@ -39,23 +39,6 @@ u32 pmu_raw_readl(u32 offset)
>   return readl_relaxed(pmu_base_addr + offset);
>  }
>  
> -static void exynos_power_off(void)
> -{
> - unsigned int tmp;
> -
> - pr_info("Power down.\n");
> - tmp = pmu_raw_readl(EXYNOS_PS_HOLD_CONTROL);
> - tmp ^= (1 << 8);
> - pmu_raw_writel(tmp, EXYNOS_PS_HOLD_CONTROL);
> -
> - /* Wait a little so we don't give a false warning below */
> - mdelay(100);
> -
> - pr_err("Power down failed, please power off system manually.\n");
> - while (1)
> - ;
> -}
> -
>  void exynos_sys_powerdown_conf(enum sys_powerdown mode)
>  {
>   unsigned int i;
> @@ -85,6 +68,23 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
>   }
>  }
>  
> +static void exynos_power_off(void)
> +{
> + unsigned int tmp;
> +
> + pr_info("Power down.\n");
> + tmp = pmu_raw_readl(EXYNOS_PS_HOLD_CONTROL);
> + tmp ^= (1 << 8);
> + pmu_raw_writel(tmp, EXYNOS_PS_HOLD_CONTROL);
> +
> + /* Wait a little so we don't give a false warning below */
> + mdelay(100);
> +
> + pr_err("Power down failed, please power off system manually.\n");
> + while (1)
> + ;
> +}
> +
>  static int pmu_restart_notify(struct notifier_block *this,
>   unsigned long code, void *unused)
>  {
> 

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

Re: [PATCH v4 7/9] ARM: EXYNOS: split up exynos5420 SoC specific PMU data

[Krzysztof Kozlowski]

On 10.11.2015 20:43, Pankaj Dubey wrote:
> This patch splits up mach-exynos/pmu.c file, and moves exynos5420,
> PMU configuration data and functions handing data into exynos5420
> SoC specific PMU file mach-exynos/exynos5420-pmu.c.
> 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/mach-exynos/Makefile |   2 +-
>  arch/arm/mach-exynos/exynos-pmu.h |   1 +
>  arch/arm/mach-exynos/exynos5420-pmu.c | 280 
> ++
>  arch/arm/mach-exynos/pmu.c| 263 ---
>  4 files changed, 282 insertions(+), 264 deletions(-)
>  create mode 100644 arch/arm/mach-exynos/exynos5420-pmu.c
> 
> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> index bfb23a5..2d58063 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -11,7 +11,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
> -I$(srctree)/$(src)/include -I$(srctree)
>  
>  obj-$(CONFIG_ARCH_EXYNOS)+= exynos.o pmu.o exynos-smc.o firmware.o \
>   exynos3250-pmu.o exynos4-pmu.o \
> - exynos5250-pmu.o
> + exynos5250-pmu.o exynos5420-pmu.o
>  
>  obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
>  obj-$(CONFIG_PM_SLEEP)   += suspend.o
> diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
> b/arch/arm/mach-exynos/exynos-pmu.h
> index 003fa6d..306f5c7 100644
> --- a/arch/arm/mach-exynos/exynos-pmu.h
> +++ b/arch/arm/mach-exynos/exynos-pmu.h
> @@ -38,6 +38,7 @@ extern const struct exynos_pmu_data exynos4210_pmu_data;
>  extern const struct exynos_pmu_data exynos4212_pmu_data;
>  extern const struct exynos_pmu_data exynos4412_pmu_data;
>  extern const struct exynos_pmu_data exynos5250_pmu_data;
> +extern const struct exynos_pmu_data exynos5420_pmu_data;
>  
>  extern void pmu_raw_writel(u32 val, u32 offset);
>  extern u32 pmu_raw_readl(u32 offset);
> diff --git a/arch/arm/mach-exynos/exynos5420-pmu.c 
> b/arch/arm/mach-exynos/exynos5420-pmu.c
> new file mode 100644
> index 000..5810afe
> --- /dev/null
> +++ b/arch/arm/mach-exynos/exynos5420-pmu.c
> @@ -0,0 +1,280 @@
> +/*
> + * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
> + *   http://www.samsung.com/
> + *
> + * EXYNOS5420 - CPU PMU (Power Management Unit) support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "exynos-pmu.h"
> +
> +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} },
> + { 

RE: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Pavel Fedin]

 Hello!

> >> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in 
> >> > the
> >> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, 
> >> > Tacs.
> >> > +Each value is specified in cycles and has the 
> >> > following
> >> > +meaning and valid range:
> >> > +Tacp : Page mode access cycle at Page mode (0 - 
> >> > 15)
> >> > +Tcah : Address holding time after CSn (0 - 15)
> >> > +Tcoh : Chip selection hold on OEn (0 - 15)
> >> > +Tacc : Access cycle (0 - 31, the actual time is 
> >> > N + 1)
> >> > +Tcos : Chip selection set-up before OEn (0 - 15)
> >> > +Tacs : Address set-up before CSn (0 - 15)
> >>
> >> This is not easily extended. Perhaps a property per value instead.
> >
> >  We had a discussion with Krzysztof about it, he agreed with this form of 
> > the property.
> > My concern was that it's just too much typing, and makes little sense 
> > because these
> > settings always go together. If register layout changes, or parameter set 
> > changes in
> > incompatible way, then it's another device, not exynos-srom anymore.
> >  So would you agree with that, or is your position strong?
> 
> I'm thinking for a new version of the controller which could add (or
> remove) new timing parameters, but then I guess you can interpret the
> field differently based on the compatible string. Anyway, your problem
> to deal with.

 Of course, my thought is that if compatible string is different,
then it's already a different device. And of course it would have different 
parameters.
 So, OK, i'll post new version with fixed documentation today.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


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

Devicetree gpu entry for Mali400-MP4 embedded in Exynos4412 Prime SoC'S

[Thomas Pietrowski]

Hi,

while using the mainline kernel on my Odroid U3+ for a while, I tried
to make it working with the latest ARM Mali driver supported by my
vendor (Hardkernel), which is r5p0.
I found a pdf document on the net for the Exynos4412 and also took a
look at the dt entry by Tobias Jakobi, who has got a individual dt
implementation for an older (r4p0) mali driver.
But I ended with error messages at driver initialization, so added a
question at community.com [1] to understand the reason and they said
that there is a lot wrong in the dt entry. So I assume that there are
much differences between Exynos4412 and Exynos4412 Prime (?).

Additionally: Is it possible to merge dtb files? Just in case I have
an installation with a kernel + dtb's preinstalled, is it possible to
cat the missing gpu@ entry from a seperate dtb? Or better: Are you
planning to add the missing gpu@ entries? I know Greg Kroah-Hartman
made a statement in the past about the mali driver, but as the device
trees just have to describe the hardware layout it shouldn't be a
problem adding these entries, isn't it?

Regards

[1] https://community.arm.com/thread/9145
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Arnd Bergmann]

On Wednesday 11 November 2015 15:14:48 Mauro Carvalho Chehab wrote:
>  rename include/media/{ => platform}/exynos-fimc.h (100%)
>  rename include/media/{ => platform}/mmp-camera.h (100%)
>  rename include/media/{ => platform}/omap1_camera.h (100%)
>  rename include/media/{ => platform}/omap4iss.h (100%)
>  rename include/media/{ => platform}/s3c_camif.h (100%)
>  rename include/media/{ => platform}/s5p_hdmi.h (100%)
>  rename include/media/{ => platform}/sh_mobile_ceu.h (100%)
>  rename include/media/{ => platform}/sh_mobile_csi2.h (100%)
>  rename include/media/{ => platform}/sh_vou.h (100%)
>  rename include/media/{ => platform}/sii9234.h (100%)
>  rename include/media/{ => platform}/soc_camera.h (100%)
>  rename include/media/{ => platform}/soc_camera_platform.h (98%)
>  rename include/media/{ => platform}/soc_mediabus.h (100%)

This still seems to be a mix of various things. Some of these are interfaces
between drivers, while others declare a foo_platform_data structure that
is used to interface between platform code and the driver.

I think the latter should go into include/linux/platform_data/media/*.h instead.

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

Re: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Rob Herring]

On Wed, Nov 11, 2015 at 12:44 AM, Pavel Fedin  wrote:
>  Hello!
>
>> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in 
>> > the
>> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, 
>> > Tacs.
>> > +Each value is specified in cycles and has the 
>> > following
>> > +meaning and valid range:
>> > +Tacp : Page mode access cycle at Page mode (0 - 
>> > 15)
>> > +Tcah : Address holding time after CSn (0 - 15)
>> > +Tcoh : Chip selection hold on OEn (0 - 15)
>> > +Tacc : Access cycle (0 - 31, the actual time is N 
>> > + 1)
>> > +Tcos : Chip selection set-up before OEn (0 - 15)
>> > +Tacs : Address set-up before CSn (0 - 15)
>>
>> This is not easily extended. Perhaps a property per value instead.
>
>  We had a discussion with Krzysztof about it, he agreed with this form of the 
> property.
> My concern was that it's just too much typing, and makes little sense because 
> these
> settings always go together. If register layout changes, or parameter set 
> changes in
> incompatible way, then it's another device, not exynos-srom anymore.
>  So would you agree with that, or is your position strong?

I'm thinking for a new version of the controller which could add (or
remove) new timing parameters, but then I guess you can interpret the
field differently based on the compatible string. Anyway, your problem
to deal with.

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

Re: [PATCH v9 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Rob Herring]

On Fri, Oct 30, 2015 at 09:09:15AM +0800, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
> 
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
> 
> Tested-by: Heiko Stuebner 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---

I didn't find this one in v10. Did it get dropped?

> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>   hpd when hpd detect failed.
> 
> Changes in v2: None
> 
>  .../bindings/display/bridge/analogix_dp.txt|  4 ++-
>  .../bindings/display/exynos/exynos_dp.txt  |  1 +
>  .../display/rockchip/analogix_dp-rockchip.txt  |  1 +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 
> +++---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
>  6 files changed, 47 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> index 7659a7a..74f0e80 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> @@ -22,6 +22,9 @@ Required properties for dp-controller:
>   from general PHY binding: Should be "dp".
>  
>  Optional properties for dp-controller:
> + -analogix,need-force-hpd:
> + Indicate driver need force hpd when hpd detect failed, this
> + is used for some eDP screen which don't have hpd signal.

This should be a generic property.

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

Re: [PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem

[Emil Velikov]

Hello Marek,

On 10 November 2015 at 13:23, Marek Szyprowski  wrote:
> Dear All,
>
> This patch series introduces a new life into Exynos IPP (Image Post
> Processing) subsystem by integrating it (transparently for userspace
> applications) with Exynos DRM core plane management. This means that all
> CRTC drivers transparently get support for standard features of IPP
> subsystem like rotation and scaling.
>
> Support for features not supported natively by CRTC drivers is
> implemented with a help of temporary framebuffers, where image data is
> processed by IPP subsystem before performing the scanout by a CRTC driver.
>
> This patchset is a first version of this 'new feature' and I would like
> get some comments on the proposed approach. I plan to continue working
> on enhancing Exynos DRM drivers and especially do the cleanup the IPP
> subsystem.
>
> Most of the new features are added by the last 2 patches. All other
> patches are bugfixes in various Exynos DRM subdrivers and significant
> core rewrite - introducing a subclass of drm_plane_state was needed and
> all drivers have been converted to use it. Some initial cleanups in IPP
> subsystem were also needed to let Exynos core to call it internally from
> the driver core. This part will be cleaned even more in the future.
>
>
> My solution has been tested on Exynos4412-based Odroid U3 and
> Exynos5420-based Odroid XU3. To check rotation, cropping and scaling
> I've developed a simple test application, which use atomic mode
> setting/page flipping API. You can download it here:
>
> https://git.linaro.org/?p=people/marek.szyprowski/atomictest.git
>
Can I interest you in up-streaming this code into place such as libdrm
? This way other developers can benefit from your tool.

Admittedly I've not looked at the tool but it seems to me that it
duplicates some of the functionality we already in modetest (+atomic).
The latter of which send by your colleague Hyungwon Hwang [1] (and I
seemingly forgot do a final review/push). If you can share a few
cycles worth of review and/or importing your app.

Thanks
Emil

[1] http://lists.freedesktop.org/archives/dri-devel/2015-September/090748.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 v8 10/17] phy: Add driver for rockchip Display Port PHY

[Heiko Stuebner]

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:30:33 schrieb Yakir Yang:
> Add phy driver for the Rockchip DisplayPort PHY module. This
> is required to get DisplayPort working in Rockchip SoCs.
> 
> Reviewed-by: Heiko Stuebner 
> Signed-off-by: Yakir Yang 

a general thing I have been pondering, we should probably move the
dp-phy under the GRF. Similar to the new power-domains being
a full child of the PMU, the dp-phy is a full child-device of the GRF.

That would include:
- making the GRF a simply-mfd (just adding that property)
- moving the dts node under it
- making the driver get its regmap from its parent (just like
  drivers/soc/rockchip/pm_domains.c does)


The usbphy is another example of that, and I think I'll be moving it
below the grf as well.


Heiko

> ---
> Changes in v8:
> - Fix the mixed spacers on macro definitions. (Heiko)
> - Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
> 
> Changes in v7:
> - Simply the commit message. (Kishon)
> - Symmetrical enable/disbale the phy clock and power. (Kishon)
> 
> Changes in v6: None
> Changes in v5:
> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
>   the exist "grf" syscon already. And rename the example DT node from
>   "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> - Add deivce_node at the front of driver, update phy_ops type from "static
>   struct" to "static const struct". And correct the input paramters of
>   devm_phy_create() interfaces. (Heiko)
> 
> Changes in v4:
> - Add commit message, and remove the redundant rockchip_dp_phy_init()
>   function, move those code to probe() method. And remove driver .owner
>   number. (Kishon)
> 
> Changes in v3:
> - Suggest, add rockchip dp phy driver, collect the phy clocks and
>   power control. (Heiko)
> 
> Changes in v2: None
> 
>  drivers/phy/Kconfig   |   7 ++
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-rockchip-dp.c | 155 
> ++
>  3 files changed, 163 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-dp.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 7eb5859d..7355819 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
>  
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> +   Enable this to support the Rockchip Display Port PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>   tristate "ST SPEAR1310-MIPHY driver"
>   select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 075db1a..b1700cd 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  += 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..c82c22f
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,155 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_SOC_CON12   0x0274
> +
> +#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
> +#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
> +
> +#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
> +#define GRF_EDP_PHY_SIDDQ_ON0
> +#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device  *dev;
> + struct regmap  *grf;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
> + int ret;
> +
> + if (enable) {
> + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> +GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
> +GRF_EDP_PHY_SIDDQ_ON);
> + if (ret < 0) {